My theme’s loop started with start_wp() which works fine for everything except the_tags().
I replaced start_wp() with the_post() and the built into 2.3 tags function started showing up.
Tag: WordPress (page 11 of 13)
On my back up site I’ve restored my WordPress blog and did the site_url thing in wp-config.php. Then I installed the WordPress 2.3 beta on top using svn.
Beta 2 is working really well and the UTW tag importer does work. When I use the default theme the tags show up; when I try to use the the_tags() in my theme I get nothing. The built in tags are a little rough and lack UTW’s simple features like ‘Add existing tag’. You can re-use tags but if you fat finger the tag, then you get one off. Also the importer gets the name “Just Stupid” with a hyphen where the space should be.
I will also play around with the new wp_tag_cloud() to see what results I get. It’s prpbably not as slick as UTW’s and CSS styling will have to be done to get the changes is color.
Probably a problem with my theme I’ll keep working on it. In the worst case scenario I’ll just continue to use UTW till the kinks are worked out.
In the WordPress support forum (very serious neener neener neener ;-P ) I had seen a request to add numbers to each post title. Giving it some thought and testing here is one way it can be done.
In the index.php file for your theme, before the loop (I put it right after get_header line) add the following code:
<?php if ( $paged < 2 ) {
$my_paged = 0;
} else {
$my_paged = ($paged - 1) * get_option('posts_per_page');
}
$count = 1;
?>
Now inside the loop in the same file put this php code where ever you want the number to appear.
<?php echo $my_paged + $count . ". "; ?>
A good place is right after the <h2> in the default theme, so this line
<h2><a href="<?php the_pemalink() ?>...
becomes
<h2><?php echo $my_paged + $count . ". "; ?><a href="<?php the_pemalink() ?> ...
The count variable needs to be incremented for each post. Before the end of the loop put this line in
<?php $count = $count + 1; ?>
On the default theme this should go right above the <?php endwhile; ?>. This will produce a number with a period and a space before the title.
Since it is before the <a> tag it will not be part of the link to the post.
Updated: I’ve rearranged the code a little bit so that I could selectively translate parts of the notice. The updated javascript sections is located here.
– – – – – – – – – – – – – – –
I had to switch back to the old copy of the ATPP WordPress plugin. My problem is most likely due to a configuration problem on my end, but I was getting hammered by HEAD and GET requests from Babelfish and WorldLingo.
I managed to add some javascript to my sidebar so that browser URL is compared with the URL the server thinks it served. If the two are different then the page is translated and a notice is displayed.
Here is the code.
<script type=”text/javascript”>
<!–
var browser_url = location.pathname
var server_url = “<?php echo(@$_SERVER[‘REQUEST_URI’]); ?>”
var orig_link = “<?php bloginfo(‘url’);echo(@$_SERVER[‘REQUEST_URI’]); ?>”
if ( browser_url !== server_url )
{
document.write(‘<div class=”trans-notice”>’)
document.write(‘<p>Please note: This page was originally written in English.</p>’)
document.write(‘<p>The text has been translated using an online service such as Google or Babelfish.</p>’)
document.write(‘<p>The original page can be viewed <a href=”‘,orig_link,'”>here</a>.</p>’)
document.write(‘</div>’)
document.write(‘<br />’)
}
//–>
</script>
If you click on http://blog.dembowski.net/archives/de/ the server will still see it as http://blog.dembowski.net/archives/ (without the /de/ at the end). The browser will see the real URL with the /de/ and compare what the server is reporting. If the two are different then the notice is displayed.
The notice will also be displayed if someone used /?p=123 to access a post. That’s not how my permalinks are setup so I’m not concerned about it.
Well be careful what you wish for. The new version of the translator plugin has a load balancing/fail over option so that if the primary translator is unavailable and does not respond in time then the request gets sent to the next translation engine.
That is a very cool option. It also means your webserver gets hit massively by the translation engines. My web traffic went from 5,000 hits (900 visits) last week to 21,000 hits yesterday.
In terms of network traffic that’s not even 100kbs. In terms of application hits (Apache web server) that’s huge. I’ve rolled back the version from 5.01 back to 4.0. I had to load up phpmyadmin and zap the options from the plugin to get 4.0 working again.
The new version has some very cool options. If I can turn off the load balancing and set the error page that comes up to my own page then I’d be set.
I’ll e-mail the author and get it sorted out.
Update: I’ve found the problem. It had nothing to do with ATPP, it was how I configured my logging software.
In 2006 I started playing with a translation plugin for WordPress. It was free and I liked the 1.0 version. When the author took the next version for purchase only (no longer free) I waited for version 4.0 and plunked down the money to obtain it.
The plugin ATPP works reasonably well. It does not do the actual translations (that would make for huge plugin!) instead it sends the data to Google or Babelfish per the configuration of that language.
Translation has led to some interesting comments from viewers. I get many hits from search engines which include the translated web pages. The viewers don’t select the translate button, they go straight to the translated page.It’s all machine translated so the basic gist is preserved but I’m told the grammar and flow is awful. Lily says the Chinese text reads like those vendors in Chinatown who are hawking things in English, and they don’t speak English. One commenter stated in Spanish that he’s never seen such bad language.
I just received version 5.01 of ATPP and it now adds the ability to check if the page is translated or not. With the inclusion of the following PHP code in your sidebar.php (or anywhere you’d like; I may change it) you can now warn your readers:
<?php if(function_exists(“tgInTranslatedPage”) && (tgInTranslatedPage())) { ?>
<!–skip translation–>
<div class=”trans-notice”>
<p>Please note: This page was originally written in English.</p>
<p>The text has been translated using an online service such as <a href=”http://www.google.com/translate_t”>Google</a> or <a href=”http://babelfish.yahoo.com/”>Babelfish</a>.</p>
<?php
$original=@$_SERVER[‘REQUEST_URI’];
?>
<p>The original post can be viewed <a href=”<?php bloginfo(‘url’);_e($original); ?>”>here</a>.</p>
</div>
<!–end skip translation–>
<br />
<?php } ?>
I wrapped it in a <div> so that I can style it easily. In my style.css file I added
.trans-notice {
font-family: “Trebuchet MS”, Georgia, Arial, serif;
font-size: 0.9em;
border:#ccc 1px solid;
background-color:#FAFAFA;
margin: 0 5px;
}
.trans-notice p {
margin: 7px;
}
This gives a warning in English that will hopefully explain why the text reads so poorly.
I was checking out my server logs (gripping reading, could not put it down) when I saw these two entries:
208.78.98.108 - - [09/Jul/2007:20:28:07 -0400] "GET /wp-pass.php?_wp_http_referer=http://topnlpsites.com/images/gif/echo.txt? HTTP/1.1" 403 860 "-" "libwww-perl/5.803" 81.169.188.151 - - [09/Jul/2007:20:54:39 -0400] "GET /wp-pass.php?_wp_http_referer=http://doublezer0.free.fr/echo.txt? HTTP/1.1" 403 1032 "-" "libwww-perl/5.69"
File wp-pass.php? Where’d that come from?
See the BUGTRAQ explanation here. By passing arguments to wp-pass.php, the wp-pass.php file will send the requesting browser to the URL that wp_http_refferer points to. By using a simple script the WordPress installation is easily verified as susceptible.
The bad buy sends out a SPAM or bogus link that points to a WordPress installation and that WordPress blog redirects the request to where ever the attacker wants. This is not earth shattering but really annoying.
Luckily Apache’s .htaccess is our friend. In my blog root at the end of my .htaccess file I added the following two lines:
RewriteCond %{REQUEST_URI} ".*wp-pass.php"
RewriteRule .* - [F]
I do not have any password protected posts so I don’t use that file (which is all I gather it is for…) and after implementing this my blog continues to work fine. Any requests that match that rewrite conditions gets a return value of 403: Forbiden.
This is to be fixed in WordPress 2.2.2 says the posting. The BUGTRAQ posting also mentions wp-includes/pluggable.php, wp-includes/functions.php maybe vulnerable due to the use of problematic code.
I’ve had some free time so I’ve added so I went through all my posts (153!) and made sure they validate as XHTML strict. I’ve also played with this theme and added the image rotator for the header.
Using Matt’s rotate.php script, I created a directory called and dumped some images in there. The images were lifted from Stefan’s Flickr page. His pictures are great and I was using one of his images as a banner already.
In my CSS file I replaced the
#header {
background: url(img/bus.jpg) no-repeat bottom;
with
#header {
background: url(img/rotate.php) no-repeat bottom;
Per the CSS for my header the files should be 700×175; which I forgot and created 700×200 images. No big deal the CSS fixes the images to fit.
The fun part was getting the caching to work so I could see the files and how they look. Internet Explorer and Firefox cache the page to make the whole experience is faster. But that also means that when I reloaded the page the banner would not necessarily change.
Using Google I found that adding the following right below the <head> statement in my header.php would get Internet Explorer and Firefox to reload the whole page with a new banner (most of the time).
<meta http-equiv=”Expires” content=”Tue, 01 Jan 1980 1:00:00 GMT” />
<meta http-equiv=”Pragma” content=”no-cache” />
I turned it off after my curiosity was satisfied. Caching is your friend and should be respected.
Like waiting for the odometer to roll over.
I moved WordPress back to the primary server. I took a working copy of all the files and database from the backup and restored it to the primary and poof it works.
Yesterday I did get a PHP update for Opensuse, that might have been part of it.
