After successfully corrected the error caused by the WordPress plugin called Pagination which I blogged at my post, WordPress database error You have an error in your SQL syntax, I again discovered another error encountered by the blog as logged in the error_log file. The error message says:

WordPress database error Illegal mix of collations (latin1_swedish_ci,IMPLICIT), (utf8_general_ci,COERCIBLE), (utf8_general_ci,COERCIBLE) for operation ‘replace’ for query  SELECT SQL_CALC_FOUND_ROWS  wp_posts.* FROM wp_posts  WHERE 1=1 AND ((((LENGTH(wp_posts.post_content) – LENGTH(REPLACE(LCASE(wp_posts.post_content), ‘韩国性爱电影’, ”)))/18) + ((LENGTH(wp_posts.post_title) – LENGTH(REPLACE(LCASE(wp_posts.post_title), ‘韩国性爱电影’, ”)))*3/18) + ((LENGTH(wp_posts.post_content) – LENGTH(REPLACE(LCASE(wp_posts.post_content), ‘video’, ”)))/5) + ((LENGTH(wp_posts.post_title) – LENGTH(REPLACE(LCASE(wp_posts.post_title), ‘video’, ”)))*3/5) + 0)>0) AND wp_posts.post_type != ‘revision’ AND (wp_posts.post_status = ‘publish’ OR wp_posts.post_author = 1 AND wp_posts.post_status = ‘private’)  ORDER BY  ((LENGTH(wp_posts.post_content) – LENGTH(REPLACE(LCASE(wp_posts.post_content), ‘韩国性爱电影’, ”)))/18) + ((LENGTH(wp_posts.post_title) – LENGTH(REPLACE(LCASE(wp_posts.post_title), ‘韩国性爱电影’, ”)))*3/18) + ((LENGTH(wp_posts.post_content) – LENGTH(REPLACE(LCASE(wp_posts.post_content), ‘video’, ”)))/5) + ((LENGTH(wp_posts.post_title) – LENGTH(REPLACE(LCASE(wp_posts.post_title), ‘video’, ”)))*3/5) + 0 DESC, POST_DATE DESC  LIMIT 670, 10 made by require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts

The error message is already clear… there was an illegal mix of collations between latin1 and the utf8. With this, my instinct told me that there might be some tables in the database used by my blog that are using the latin1 collation or charset while there are others in utf8.

And it might be true because this blog started to exist on March 2006. And the WordPress software at that time was using the latin1 charset. Then there was a time that the utf8 collation has been made available and became the default collation of the WordPress.

So, I logged in to my cPanel, opened the MyPHPAdmin script and checked the tables of the database used by this blog. And yes, it’s true. The tables used by this blog are still using the Latin1 collation which in conflict to the WordPress Collation default setting which is already in Utf8.

Now, I am sure that there is a need for me to convert the tables from using the Latin1 to Utf8.

Here’s what I did:

1. Through the PHPMyAdmin Script, I downloaded the affected tables in the form of database dumps.
2. I opened the downloaded database dumps file using the Windows Wordpad.
3. I replaced all the CHARSET=Latin1 with CHARSET=utf8 using the Find and Replace feature of the Windows Wordpad.
4. Then I saved the file.
5. Using the MyPHPAdmin script, I dropped all the affected tables.
6. Then I imported the downloaded database dumps into the database.

That’s it.

I checked the tables of that database and yes, the collations error was already corrected.

While trying to correct the error that has been logged in the error_log file regarding suhosin.so which I blogged at my post, PHP Warning: Module ‘suhosin’ already loaded in Unknown on line 0, I also discovered another error that this blog has encountered. This time it is related to the database and the error message says:

WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1 for query SELECT count(*) FROM  made by require, require_once, include, pagination

By looking at the error message above, my instinct told me that this error might be caused by a particular WordPress Plugin I installed for my blog.

I checked the codes of every activated plugin, looking for the code, SELECT count(*) FROM. And I found this at the codes of the plugin called Pagination.

I again, checked the errors recorded on the error_log file and I found this one which I think related to the above error:

WordPress database error Unknown column ‘post_id’ in ‘field list’ for query SELECT count(DISTINCT post_id) FROM wp_posts  INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) INNER JOIN wp_term_taxonomy ON (wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id)  WHERE 1=1  AND wp_term_taxonomy.taxonomy = ‘category’ AND wp_term_taxonomy.term_id IN (’44′) AND wp_posts.post_type = ‘post’ AND (wp_posts.post_status = ‘publish’)  ORDER BY wp_posts.post_date DESC made by require, require_once, include, pagination

In order to verify if this error is caused by the WordPress plugin called Pagination, I searched this code, SELECT count(DISTINCT post_id) FROM,  from its codes. And I was right.

So, I don’t have a choice but to deactivate the plugin to save my blog from these errors.

Post Revisions tracking system was introduced on the WordPress version 2.6. With this, everytime you save your post or the WordPress system automatically saved your post, it also creates a new data in your wp-posts table in the database. But this data has the type called “revision”.

The very purpose of this is for you to be able to get the previous copy of your revision if ever you did something wrong with the latest revision of your post.

But the negative effect of this is that your database is getting bigger especially if you saved your post several times before posting it, or if you are editing your posts several times. And as you already know, bigger database file will just be a burden of your server, thus slowing your site, if not crashing it off.

Turn Off Post Revisions

You can however turn off the Post Revisions Tracking System. That is if you think you don’t need this kind of feature. Just follow the steps below:

Step 1: Log-in to your cPanel.

Step 2: Find the wp-config.php file. It is usually found in the WordPress directory.

Step 3: Edit the wo-config.php file and insert this: define(‘WP_POST_REVISIONS’, false);

Step 4: Save the file.

So, now the feature has been turned off already.

Delete Post Revisions from the Database

Now, if this feature has been turned on for a long time already, then I am sure that there are lots of post revisions entries in your database especially if you are posting a lot into your wordpress blog or site. You might need to delete them.

You can delete those entries by running the Sql command: DELETE FROM wp_posts WHERE post_type = “revision”;

You can run that code using the MyPhPAdmin of your cPanel. If you are using the WP-DBManager WordPress plugin, then you can make use of its Run SQL feature.

In my post, Negative Effect of Keyword Hijacking, I told you that I transferred all my blogs hosted by DreamHost to a new Dedicated server.

However, I found out today that my Gallery blog was still dead. I haven’t set-up an account for the blog and of course I haven’t set up the blog including its files.

So, just to make the story short, I set-up an account for the blog using the CPanel/WHM, the database, and then I immediately  uploaded all the files including the WordPress files that I recently downloaded from the server of Dreamhost. After that, I imported the back-up database of the site, and then tried to reactivate the blog.

But there’s another problem. Accessing the blog will generate this kind of error which says:

Deprecated: Assigning the return value of new by reference is deprecated in …

I don’t know yet what’s the cause of this problem. My other blogs haven’t experienced it.

I think and think… until I remembered that my other blogs have been installed with the updated Wordress software. It might be the reason why my Gallery blog generated this kind of error because I failed to update its WordPress software.

I never wasted time. I downloaded the latest version of the WordPress and uploaded the files into the server. After that… everything went fine.

After moving my blogs to a new dedicated server, I began seeing error like this:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 88078 bytes) in /home/username/public_html/wp-includes/wp-db.php on line 849

By simply reading the error, it seems that the allotted memory which is 32MB is not enough for the wp-db.php file. Then I think, the solution for this is to increase the allotted memory to, let’s say 50MB but it’s better if increased to, 64MB.

Here’s how:

Step 1: Open the wp-config.php file. It is found in your public_html folder.

Step 2: Then insert the code below just below the PHP opening tag <?PHP:

define(‘wp_memory_limit’, ’64M’);

As simple as that, and everything will be fine.

For few years already, I was using the WordPress Mobile plugin written by Andy Moore. I was already contented with it although, I found two problems such as:

1. The author of this plugin, Andy Moore, has not been updating the plugin.
2. The WP Super Cache Plugin sometimes cached the mobile version of it and it’s the one being served to non-mobile users.

But I didn’t consider them serious problems because in the first place, the plugin smoothly works with the latest version of the WordPress. And when the mobile version of the blog is being served to the non-mobile users, I would only immediately delete all the cached files using the “Delete Cache” option in the WP Super Cache Admin Page to correct the problem.

However, time came that I feel tired of deleting the cached files everytime the mobile version of the blog is being served to non-mobile users. I tried other mobile plugins… observed them… and found out that the plugin written by Andy Moore is still better in terms of server’s memory consumption.

Remember that there are at least 3,000 unique mobile visitors accessing the blog every day. With that number of unique mobile visitors, Wapple Architect Mobile Plugin for WordPress and WordPress Mobile Edition plugins simply caused the downtimes of this blog… Either of these two plugins really caused serious (major major) problem of this blog.

Take a look at the graph generated by Dreamhost for my PS account. The blue line represent the CPU load of my Dreamhost PS accout, and the red one represent the memory consumption.

At 1800 to 2300 hours, the memory consumption and the CPU load are high. That’s when the WordPress Mobile Edition plugin is being used in serving mobile edition of the blog to the mobile users. And during that time, the blog was crawling and sometimes it’s down (503 error).

At 2400 hours, I deactivated the WordPress Mobile Edition plugin and reactivated the WordPress Mobile plugin by Andy Moore. That’s the time when the CPU load and the memory consumption rate had been reduced to the minimum and the blog run smoothly.

I actually did that experiment for several times before using the WordPress Mobile Edition and the Wapple Architect Mobile Plugin for WordPress, one at a time. But the results were really bad.

Now, I have no other option but to use the WordPress Mobile plugin by Andy Moore. I can disable any mobile plugins for the blog and the mobile users can still access my blog, but I need to earn money through Admob, so I need to use a mobile plugin for better conversion. After all, $300 to $600 monthly income from Admob is already a great addition to my overall online income.

Any suggestion please.

These two videos will teach you how to make your WordPress blog secure and hack-free. Just watch the videos and apply the things you’ll learn from them into your blog and then your WordPress blog will never be hacked by anybody.

Some of you knew or if not noticed already that this blog is using a theme that is not available at any WordPress theme directory. It’s because I am the one who designed and coded this theme.

I may have knowledge in creating a WordPress theme but it’s not enough for me to create an optimized and widgetized WordPress theme.

Just recently, the WordPress 3.0 was released. I immediately upgraded my blog to the latest WordPress engine thinking that nothing would go wrong. But I was wrong. I encountered lots of problem especially on the plugins that this blog is using. And one of these problems were caused by plugins that were already in widget form.

So, I realized that I really need to widgetize the theme of this blog.

Here’s what I did.

Step 1. Create a file “functions.php” and save it on the directory of the theme used by the blog. You should take note that the file name is “functions.php” not “function.php”.

Step 2. On the “functions.php” file, I wrote this code:

<?php
if ( function_exists(‘register_sidebar’) )
register_sidebar(array(‘name’=>’sidebar1′,
‘before_widget’ => ”,
‘after_widget’ => ”,
‘before_title’ => ‘<h5>’,
‘after_title’ => ‘</h5>’,
));
register_sidebar(array(‘name’=>’sidebar2′,
‘before_widget’ => ”,
‘after_widget’ => ”,
‘before_title’ => ‘<h5>’,
‘after_title’ => ‘</h5>’,
));
register_sidebar(array(‘name’=>’sidebar3′,
‘before_widget’ => ”,
‘after_widget’ => ”,
‘before_title’ => ‘<h5>’,
‘after_title’ => ‘</h5>’,
));
?>

Obviously, I was defining 3 widget areas in the sidebar of this blog. These are named as “sidebar1″, “sidebar2″ and “sidebar3″.

Step 3. Each of the 3 sidebar widget areas that I defined in “functions.php” file has a corresponding code that should be placed in the desired area on the sidebar.

For the first widget area I used this code:

<?php if ( !function_exists(‘dynamic_sidebar’)
|| !dynamic_sidebar(‘sidebar1′) ) : ?>
<?php endif; ?>

For the second widget area, I used this code:

<?php if ( !function_exists(‘dynamic_sidebar’)
|| !dynamic_sidebar(‘sidebar2′) ) : ?>
<?php endif; ?>

And below was for the third widget area:

<?php if ( !function_exists(‘dynamic_sidebar’)
|| !dynamic_sidebar(‘sidebar3′) ) : ?>
<?php endif; ?>

Step 4. Then that would be the time that I added widgets in every widget area. It could be done by clicking the “Widget” link under the “Appearance” at the WordPress admin panel. Then click and drag the desired widgets to any of the 3 widget areas.

Step 5. Checked the blog and saw that I was successful in widgetizing the WordPress of this blog.

Finale

In that simple steps, my blog’s theme is finally a widgetized one.

I thought at first doing this is hard, but it was actually too easy.

Mobile phones are now becoming better. With the release of the different smartphones, users can now browse the internet using their mobile phones. Even Google advances itself into mobile internet use.

So, bloggers especially those using the WordPress platform in running their blogs should make their blogs usable through mobile browsing. The process is easy because there are lots of WordPress mobile plugins created and made available in the internet.

Below are the top 5, or the 5 most popular Wordress plugins that will make your blogs mobile.

1. WordPress Mobile Edition – WordPress Mobile Edition is a plugin that shows an interface designed for a mobile device when visitors come to your site on a mobile device. Mobile browsers are automatically detected, the list of mobile browsers can be customized on the settings page. This plugin is written by Crowd Favorite.
2. WordPress Mobile Pack – The WordPress Mobile Pack is a complete toolkit to help mobilize your WordPress site and blog.
   It includes a mobile switcher to select themes based on the type of user that is visiting the site, a selection of mobile themes, extra widgets, device adaptation and a mobile administration panel to allow users to edit the site or write new posts when out and about.
3. Wapple Architect Mobile Plugin for WordPress – Wapple Architect Mobile Plugin for WordPress is a plugin that allows you to mobilize your blog in minutes. Every single mobile device is detected and all aspects of your blog are tailored to the visiting handset. Sites aren’t dumbed down to the lowest common denominator but instead use the features and functionality that advanced phones offer. Devices are detected by using Wapple’s advanced web services instead of relying on inferior 3rd party tools. If you view your blog with a brand new, never before seen handset, it’ll still work perfectly! Any theme you’ve installed and have styled for web will be carried across to mobile giving you a consistent look and feel for each and every one of your visitors.
4. MobilePress – MobilePress is a WordPress plugin that will render your WordPress blog on mobile handsets, with the ability to use customized themes. MobilePress is SEO enabled and detects Google, Yahoo and MSN mobile search bots. These mobile search engine bots will see the mobile version of your blog and get your mobile site indexed in the mobile search results.
5. Mowser WordPress Mobile – The dotMobi WordPress Mobile Pack is a complete toolkit to help mobilize your WordPress site and blog.  It includes a mobile switcher to select themes based on the type of user that is visiting the site, a selection of mobile themes, extra widgets, device adaptation and a mobile administration panel to allow users to edit the site or write new posts when out and about.

Hope this list helps you choose what to use. But in my part, I like the (3) Wapple Architect Mobile plugin.

I already stopped using the Global Translator plugin for WordPress. For several days already, this Make Money Online blog was running without that plugin.

The Global Translator plugin for WordPress was actually generating pages of the blog by saving the translated pages into the server. Everyday, the blog automatically got more hundreds of pages. Most of these pages were indexed by Google and other search engines.

Some of the translated pages actually topped the several SERPs of Google. And from these SERPs our blog got more traffic and also it earned money through Adsense.

In other words, Global Translator plugin for WordPress has helped our blog earn money and increase our blog’s alexa ranking from 100,000  to its current ranking which is 58,200 (current as of writing this post).

However, of these advantages of the said plugin, it also brought problems into our blog that might end up to a penalty from Google that would also lead to the lost of income, or it might end up being banned by the webhost or anything else.

Here are the problems caused by the said WordPress plugin:

Eats Up Server’s Space

The Global Translator plugin normally generate hundreds (thousands) of pages for your blog depending on how large is your blog. And those pages generated are being saved by the plugin into your server’s disk. In my blog’s case, each of the pages is about 1 MB in size.

For an account that only has limited disk space, saving hundreds of files of 1MB each could really mean a problem.

I was just fortunate that my webhost, the DreamHost, offer unlimited disk space to my account. That’s why I haven’t seen it yet as a threat to my webhosting account.

But who knows if  one day, DreamHost will change their mind and ban me from their webhosting service just because my account is eating up too much disk space.

Slowed Down the Site or Blog

On Friday, April 9, 2010, Google revealed that the speed of loading of a site is now being considered by Google when ranking websites at the Google SERP. It’s not actually the only one signal used by Google but it’s one of the 200 signals considered by Google in deciding which website or webpage should be ranked first, then next, and so on.

Because of this new development in Google Search Engine algo, I immediately checked the loading speed of the blog. And I found out that the flags (images of different flags) of different nations displayed on the blog by the Global Translator plugin contributed the slowing down of the blog.

Now if I will allow this plugin to slow down the loading speed of this blog, then I might lose important SERPs that will lead to the decrease of the blog’s traffic. And losing traffic would also mean losing blog’s income.

Google Search Engine Penalty

It’s not yet proven that the continued use of the Global Translator plugin leads to the penalty imposed by the Google search engine to the blog that is using it. But I think, time will come that that it will really happen.

To let you know, through my Google Webmasters account, I found out that Google discovered at least 56,000 “404 error” that have been caused by this plugin. It happens when Google followed a link generated by this plugin leading to the untranslated page.

But this huge number of “404 error” was not just my problem that made me worry that Google might penalized my blog. Last April 14, 2010 Google emailed me through my Google Webmasters account telling that the Googlebot experienced problem in following a large number of links within the site.

Here’s the email that I received:

Googlebot encountered problems while crawling your site http://www.selaplana.com/.

Googlebot encountered extremely large numbers of links on your site. This may indicate a problem with your site’s URL structure. Googlebot may unnecessarily be crawling a large number of distinct URLs that point to identical or similar content, or crawling parts of your site that are not intended to be crawled by Googlebot. As a result Googlebot may consume much more bandwidth than necessary, or may be unable to completely index all of the content on your site.

Google provided me the list of pages that Google thought are not necessarily be crawled. And all the pages listed are those generated by the Global Translator plugin.

Conclusion

There are other two issues that have talked by bloggers around the world regarding this plugin.

1. The terms and conditions provided by the Google’s Language API prohibit anyone to save translations into the disk or any form or device more than a certain period.
2. Some languages are not supported by Google Adsense.

But these two didn’t worry me because I made sure that the settings I set for the Global Translator plugin are in accordance with the Google terms.

Only the three problems caused by the plugin that I have discussed above really made me decide to stop using the said plugin.