To be clear, here’s the screenshot on how to do it.
Step 1 : click on 2 in the Number of Columns Screen options.

Step 2 : Update the status to Live and click on Save.

For those looking for it, I know how you feel. I just felt too stupid to not thinking about it. Admittedly, it’s probably one of the many plugins affected by the latest WordPress enhancements. I bet once rich updated the plugin to conform with the new standard, then it won’t be a problem anymore.

Source:

http://quirm.net/forum/topic.php?id=4716

Incoming search terms:

• eshop test mode
• disable eshop test mode
• disable test mode eshop
• eshop in test mode
• eshop turn off the test mode
• test mode eshop plugin

First, increase the prefork settings on httpd.conf.
<IfModule prefork.c>
StartServers 5
MinSpareServers 10
MaxSpareServers 20
ServerLimit 100
MaxClients 100
MaxRequestsPerChild 2000
</IfModule>

Second is the KeepAlive settings which was set to Off

KeepAlive Off


After doing this, it seemed like the server stabilized. However, I again hit the error the next day. So I again checked what I can change. This time, I looked at the php.ini’s memory limit.

memory_limit = 32M ; Maximum amount of memory a script may consume (8MB)

That was originally 64M. I’ll update the post later if I hit the problem again. I might tweak both the php.ini and prefork settings if it fails again.

Incoming search terms:

• apache cannot allocate memory
• Cannot allocate memory: couldn\t create child process: /opt/suphp/sbin/suphp
• Cannot allocate memory: couldnt create child process: /opt/suphp/sbin/suphp
• cannot allocate memory
• cannot allocate memory apache
• (12)Cannot allocate memory: couldn\t create child process: /opt/suphp/sbin/suphp
• cannot allocate memory couldnt create child process opt suphp sbin suphp
• cannot allocate memory couldn\t create child process wordpress
• cannot allocate memory: couldnt create child process: /opt/suphp/sbin/suphp for apache
• cannot allocate memory: couldn\t create child process: /opt/suphp/sbin/suphp for /home

I think that menu has been there for the longest time and I’m pretty sure that I’ve used that at least once if I can remember correctly. So now, I’m taking a note of it.

Incoming search terms:

• custom fields wordpress 3 2
• wordpress 3 2 custom fields
• custom fields in wordpress 3 2
• wordpress 3 2 add custom field
• ativar custom field wordpress 3 2
• where is custom fields wordpress 3 2
• wordpress 3 2 add custom fields
• wordpress 3 2 how to show custom fields
• wordpress 3 2 missing option custom content
• wordpress custom fields 3 2

1. auto-approve legitimate comments even if it has emails in it
2. prevent email scrapers from harvesting email addresses left by the commenters
3. send for manual approval any comment with one or more URL other than emails

Just place the code below anywhere on your template’s functions.php.

function Kwatog_NoSpamEmail($text){
$pattern = '/([a-z0-9])(([-a-z0-9._])*([a-z0-9]))*\@([a-z0-9])'.'(([a-z0-9-])*([a-z0-9]))+'.'(\.([a-z0-9])([-a-z0-9_-])?([a-z0-9])+)+/i';
preg_match_all($pattern, $text, $emails);
$symbols = array("@", ".");
$safeChars = array("[at]", "[dot]");
foreach ($emails[0] as $email){
$emailsafe = str_replace($symbols, $safeChars, $email);
$text = str_replace($email, $emailsafe, $text);
}
return $text;
}

add_filter('comment_text','Kwatog_NoSpamEmail');
add_filter('pre_comment_content', 'Kwatog_NoSpamEmail');


Here’s the sample output after I put in this code.

The code is not actually foolproof but it will be able to trap 90% of the scenarios. Also, the auto-change is applicable for existing and new comments.

I have no intention as of this time to convert snippet into a WordPress plugin so feel free to create one if you feel like it.

Incoming search terms:

• emailsafe jquery
• \ [a-z0-9][a-z0-9_-]*

Here’s my .htaccess placed on the /wp-content/uploads/ directory.


IndexIgnore *
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(www\.)?kwatog\.com/ [NC]
RewriteCond %{REQUEST_URI} !hotlink\.(gif|png|jpg|doc|xls|pdf|html|htm|xlsx|docx) [NC]
RewriteRule .*\.(gif|png|jpg|doc|xls|pdf|html|htm|xlsx|docx)$ http://www.kwatog.com/filenotexist.txt [NC]


What it does is that files will not be displayed if the referrer is not my own domain. It forces the user/visitor to click on the link to be able to view/download the file(only if the extension is any of those listed above). The checking is not case-sensitive (that’s what [NC] stands for).

Together with my custom codes for user access management, I was able to display and hide links based on the user profile. At the same time, search engines like Google will not be able to crawl and cache my files. So for me, it’s actually many birds in one stone and I didn’t even have to add another code on my themes and plugins (actually, I removed the custom 404). Just to be clear, I managed to get the following with this fix.

1. Prevent Google from caching and viewing my files
2. Prevent hotlinking. That is, another site will use images stored on my server to display them on another website. Another thing is that files will not be served/viewed by simply pasting the URL/URI on the address bar.
3. Forcing the users to login before downloading/viewing files they own.
4. Prevent users from viewing other user’s files when they are logged in. This is achieved by not displaying the link to the files they do not own.

Whew, that’s a lot! Unfortunately, it took me quite some time to find the solution. Actually, two nights of sleep was lost for this. And like many of the problems I’ve written before, the solution is so damn simple. By the way, the same can be implemented in NGINX (which I also use). Of course, you need to translate the directives.

Source : Unfortunately, I forgot where I got this but it’s somewhere in the WordPress.org forum. I’ll try to update the post once I find it again.

Note : The code is just a sample. It’s not actually running on this blog.

Ciao!

Incoming search terms:

• wordpress private files
• file attachment wordpress
• wordpress private downloads
• private files wordpres
• wordpress private uploads
• wordpress private files manage
• wordpress private files plugin
• wordpress private file
• wordpress share private files
• wordpress plugin files private

Here’s the case I have.
Server Setup
Type : VPS
WebServer : nginx-0.8.51
WP Version : WP 3.0.1 multisite enabled
Plugins Installed : NONE
Problem Description :
After adding new blogs on my multisite installation, the error below

‘Error establishing a database connection
This either means that the username and password information in your wp-config.php file is incorrect or we can’t contact the database server at localhost. This could mean your host’s database server is down.’

Additional Detail : The main site is accessible without any problem. The admin dashboard is configurable. So the message that there’s a problem with the login credentials is simply not true.

The Solution

It’s one of those “too simple why I did not think about that” cases. I had to change the ownership of the wp-content folder to the nginx user.

chown -R nginx:nginx /var/www/domain.com/wp-content

Viola! The problem is solved. The issue here is that when you create a new blog and your webserver (in my case, nginx) cannot write into the wp-content folder (specifically on blogs.dir), WordPress does not throw the correct error message leaving you cold in the dark. I’m not sure if there’s already a bug reported for this. But anyhow, I’ll try to figure out how to report a bug.

If in case you don’t want the webserver user(i.e, nginxuser) to own the folder, you can at least add nginxuser to the group that owns the folder and make the folder group writable (664 or 775).

usermod -G usergroup nginxuser
chmod -R 664 /var/www/domain.com/wp-content


Incoming search terms:

• wordpress multisite Error establishing a database connection
• Error establishing database connection wordpress multisite
• wordpress multisite error establishing database connection
• Error establishing a database connection wordpress multisite
• Error establishing a database connection multisite
• wordpress multisite database error
• error establishing database connection multisite
• multisite error establishing a database connection
• multisite wordpress error establishing database
• wordpress multisite error connecting to database

Step 1

Suppose that you want mod as your new table prefix, run the following in your phpMyAdmin.

RENAME TABLE wp_commentmeta TO mod_commentmeta
,wp_comments TO mod_comments
,wp_links TO mod_links
,wp_options TO mod_options
,wp_postmeta TO mod_postmeta
,wp_posts TO mod_posts
,wp_terms TO mod_terms
,wp_term_relationships TO mod_term_relationships
,wp_term_taxonomy TO mod_term_taxonomy
,wp_usermeta TO mod_usermeta
,wp_users TO mod_users;


Step 2


UPDATE `mod_options`
SET `option_name` = 'mod_user_roles'
WHERE `option_name` ='wp_user_roles'
AND `blog_id` =0;


Step 3


UPDATE `mod_usermeta`
SET `meta_key` = REPLACE( `meta_key` , 'wp_', 'mod_' )
WHERE option_name LIKE 'wp_%';

The preceding two steps are needed because in the later versions of WordPress, some tables are converted to records. Skipping these two steps will lead to permission error. To be specific, the error is as below.

You do not have sufficient permissions to access this page.

Hmn… well, that’s just it.

Usual Disclaimer

Renaming your table doesn’t mean that you’ll be safe from the bad guys (otherwise known as ‘hackers’). It’s just one of the holes to plug and will only help in hardening your installation. However, be aware that there could be other things that can break or compromised. So be vigilant and always install the latest version of WordPress.

Incoming search terms:

• table prefix home pl
• wordpress tagged with prefix


<?php ob_start(); ?>
<?php header("HTTP/1.1 404 Not Found"); ?>


For this, credit goes to wpcanada.
http://wpcanada.ca/2008/03/20/ie-and-custom-error-pages/

This is also touched in weblogtoolscollection.com at http://weblogtoolscollection.com/archives/2004/07/31/gzip-compression-issue-in-wordpress-12-mingus/

Note: ob_start() is a PHP function Turn on output buffering… whatever that means.

Incoming search terms:

• header(\HTTP/1 1 404 Not Found\); not working wordpress
• ie 404 page
• ob_start header 404
• wordpress 404 internet explorer
• wordpress 404 on ie not on firefox
• wordpress 404 php not working


<?php get_cat_name( $cat_id ); ?>


Cool!

Reference: http://codex.wordpress.org/Function_Reference/get_cat_name

Incoming search terms:

• get_category_name
• wp get_category_name
• get_category_name wordpress
• get category name wordpress
• wp get category title
• wp get category name
• wordpress sql category name
• wordpress get the category title
• the_category_name
• get_category_title wordpress

You do not have sufficient permissions to access this page

The supposed permission problem has occured before and mainly involves plugins. For older version of wordpress, your problem may be solved by one or both of the

• Change of table prefix - I suggest you visit this to solve that problem. And it also solves a string of other things, too.
• Failed Upgrade - If you used an automatic upgrade and failed, it is possible that the version number saved in the database is already updated. You can force upgrade it by updating the your version number. Another alternative is by using MarkAquit’s script here

However, these solutions are only applicable for older versions of WordPress. If you have a clean install, you should not encounter this. That’s why it didn’t work and was back to square one of investigation. Upon further checking, it turned out that the problem is related to old plugins. Apparently, there are plugins that was written before the current releases and whose parts of the code is no longer compliant with the current version of WordPress.

Finding the offending plugin is a bit tricky especially if you are using a lot of plugins. Luckily, I only encounter this in a contact page plugin and replace it accordingly with a new plugin which was released lately. The problem with my older plugin is that there’s no more active development. And so when some of the codes were deprecated, the plugin fails.

So what’s the problem then? Old Plugins.

Incoming search terms:

• wordpress plugins You do not have sufficient permissions to access this page