Increasing the memory_limit

Having your memory_limit be set too low can cause a lot of problems. If you get a blank white screen in your admin area, or if you get an error something like the following:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /home/username/public_html/mywordpress/myfile.php(1005)

Then you need to check your memory_limit. (As always, plugins could be problem too, so be sure to deactivate those in testing your problem-fixers).

Put very simply, and according to the WordPress documentation, here are some ways to change this:

  • Increase the amount of memory a PHP script may consume. Note: If using a shared hosting service, you may need to ask your host to increase the limit.
  1. Increase the memory limit setting in php.ini (e.g. memory_limit = 64M ;). Many hosts may not allow this.
  2. Increase the memory limit via .htaccess (e.g. php_value memory_limit 64M). Many hosts may not allow this.
  3. Increase the memory limit via wp-config.php (e.g. define('WP_MEMORY_LIMIT', '64MB');)

My preferred way of doing it, is to use the php.ini file. Here is an example of how to do so with BlueHost, though the tips will likely help with any host that allows you to edit the php.ini file.

First, you will need to install your php.ini file. You can do this from the PHP Config icon in your cPanel.

While you are in the PHP Config area, also set your PHP mode to PHP5 (Single php.ini).

Once your php.ini file has been installed, it will be uploaded under the name php.ini.default and found in your public_html directory(folder). If you have an existing php.ini file in your public_html, rename it to php.ini.bak, then rename your php.ini.default to: php.ini

Once you have done that, you may just find that your problems are solved!

However, you may also find that they are not yet solved, in which case, edit your php.ini, look for the memory_limit line, and make sure it is set to 64M. If it is already set to 64M, try increasing it to 128M.

memory_limit 128M

That should be it! You’re done!

Maybe… If it still doesn’t work, keep reading, otherwise, rejoice and carry on with your life.

Now, if your WordPress site resides in a subfolder of public_html, you may also need to check your .htaccess file within that subfolder.

If you do not have hidden files enabled, you will need to make sure they are enabled, since .htaccess is a hidden file. Make sure that your subfolder’s .htaccess file does not have a line like the following:

AddHandler application/x-httpd-php5 .php <—– This is a bad line for a .htaccess in a subfolder.

If you see such a line, remove it and, if you’d like, replace it with the following line(notice the subtle “s” which makes all the difference in the world… or at least it does on my BlueHost account).

AddHandler application/x-httpd-php5s .php <—– This is a good line

That’s it! Now you can rejoice and be glad!

If you still have problems, drop me a comment, or checkout the WordPress support forums

Adjusting WordPress Privacy

There are times when you want to set up a site for specific people to access and no one else. You want to keep it hidden from the general public/the rest of the world.

WordPress has three built-in options which will help you adjust those needs, however, I will also cover here a few more possibilities which can help you keep your site private.

Lets start with the First three options provided, in WordPress’s docs own words:

  1. I would like my blog to be visible to everyone, including search engines (like Google, Bing, Technorati) and archivers – This is the setting used by most blogs. It lets everyone read your blog and allows your blog to be included in search engines and other content sites.
  2. I would like to block search engines, but allow normal visitors – If you want all human visitors to be able to read your blog, but want to block web crawlers for search engines, this is the setting for you.
  3. I would like my blog to be visible only to users I choose – You would use this setting to create a private blog. If selected, another area will appear where you can control which users will be able to log into your blog to read it (those users will only be able to read your blog, they will not get access to your dashboard to edit your blog, please see this section if you want to give people edit access):

WordPress Privacy Options

Excellent options, but not necessarily enough.

Sometimes you may want to keep your site private but do not want people to have to log in to see it. In this case, option number 2 is the best for you but, if you use cPanel, you also know that the structure might allow someone to find your site from another location. We will deal with that here.

Suppose your blog installation is in a location like public_html/blog

You may block people from finding it, but anyone who accesses the site at public_html might end up finding it anyway by using /blog. We can stop this attempt in its tracks using the .htaccess file.

To block subdirectories from being accessed from the root domain, use the following .htaccess code:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?$ [NC]
RewriteCond %{REQUEST_URI} ^/yourblogdirectory/(.*)$
RewriteRule ^(.*)$ – [L,R=404]

OR, if you have multiple subdirectories you want to block access to from your root domain, you can do something like the following. (Adding or adjusting as many of the [OR] lines as needed:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?$ [NC]
RewriteCond %{REQUEST_URI} ^/yourblogdirectory/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/yourblogdirectory/otherblog/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/otherdirectory/(.*)$
RewriteRule ^(.*)$ – [L,R=404]

Excellent! This will keep people from accessing your blog through a subdirectory!

But what if you want to block access to a subdomain instead of a subdirectory?

My favorite thing to do in this case, just for fun and enjoyment, is to redirect subdomain visitors to another location like google. In cPanel’s structure, if you have an Addon Domain, we all know it is also accessible through a subdomain from your primary domain. This will stop people from being able to access that subdomain to try to get to your Addon Domain site.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^$ [OR]
RewriteCond %{HTTP_HOST} ^$
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^(.*)$ [R=301,L]

Now anyone who tries to access your site by the subdomain route, instead of the correct URL, will be redirected to google. They’ll never know what hit ’em.

WordCamp Utah Re-visited. Will it Blend?!

I posted previously about WordCamp Utah and Tom Dickson’s appearance to do a quick Will it Blend for us. Now I have a video link which can be watched. Check it out sometime!

WordCamp – Will it Blend?

Simple Database Optimization

I decided to take some information I found and share it as I thought it was a very simple approach to something that many people could use.

It seems that people these days have database problems all the time and rarely know what to do about it or, even if they know there are problems, they don’t know where to start. This may help.

Generally speaking, anything after the ‘where’ clause in an SQL query needs to
have an index.


table: people::

id | name    | age | comment
0 | Billy   |  21 | I’m heavily under-caffinated.
1 | Sally   |  19 | OMG. Like, totally!
2 | Jane    |  23 | I have a pet squirrel
3 | Mark    |  30 | Whatever
4 | OldGuy  | 105 | Get off my lawn!

A simple query::

`SELECT * FROM people WHERE name = “Sally”;`

Should only return one row. If ‘name’ is indexed as it should be here (I would
use UNIQUE here), mysql only needs to retrieve the one row::

id | name    | age | comment

1 | Sally   |  19 | OMG. Like, totally!

If the column is NOT indexed, it would have to search through all 5 rows to
find the single row matching criteria. It would still only *return* one row,
but it would examine all of them

In a small table (such as this example) the speed gained by indexing may seem
negligable, but it’s when these tables grow to thousands of rows that this
becomes a problem.

Another speed trick would be to limit the number of things to grab::

`SELECT * FROM people WHERE name = “Jane” LIMIT 1;`

With the indexing mentioned above, it will still only need to pull the one row.
Without the indexing, instead of searching the entire table, it would search
long enough to find Jane, then stop, only searching 3 rows instead of 5 like
above. This would be especially useful if you use non-unique index

So why aren’t all columns indexed automatically?  There are instances where you
would never (or at least almost never) search on a specific table. In the
example given, there’s not really a common reason to ever search the ‘comment’
row, so it stays un-indexed.

Problems Deleting Old Posts or Pages

The issue of being unable to delete old posts or pages appears to have been getting better and few are still having problems with it, so hopefully you’re not one of them. Nevertheless, if you have problems, cross your fingers because this problem can be difficult to narrow down.

It tends to be, most commonly, that these problems stem from bad plugins or themes. If you have a problem being able to delete posts or pages on your site, start by deactivating all of the plugins. Afterwards, if you still have problems, switch your theme to the twentyten theme. See: Change WordPress Theme in PHPMyAdmin

If these changes fix it, then turn your plugins back on and deactivate them one by one until you find the plugin(s) or theme which is causing the problem.

Wanted Hero Books and Comics Author Brandon Sanderson's Official Site Advertising