WPshoppe

Have you ever changed something in your WordPress admin and received an error that leaves you scratching your head for 2 days and not knowing what the heck went wrong? I just experienced that while working on one of the WordPress themes.

By default, everything worked just fine. By default meaning if you set all default values (database, tables and what not during installation), there was no error of any sort. I never actually changed anything in installations and trusting WordPress security for fixing any bugs or errors it might get. So, I never got the error. But then as security loopholes and vulnerability for hacks exist in any system, people tend to make is more secure and hard to hack by changing setttings on their own. One them being the table prefixes (wp_) for WordPress.

So, during installation, there was an instance when the default wp_ table prefix was changed to gpp_. Now, this theme had theme options and its short name also used gpp_ so it saved all the theme option values within gpp_*. The table prefix gpp_ also saves one of its very important field – gpp_user_roles, gpp_ coming from the prefix which otherwise would have been wp_user_roles. This field saves who can access the admin panel.

Now, the problem was whenever I reset the Theme Options, I used to get the “You do not have sufficient privileges to access this page.” error.

I looked all over the place, googled quite a number of times and found out that there was a field called wp_user_roles and wp_ was replaced with whatever table prefix you set. I then analyzed like 5-6 times trying to create a new install of WordPress, activating the theme, saving the theme options and resetting the theme options. At last I found out that everytime I reset the theme options, all instance of gpp_option_names were getting deleted including gpp_user_roles. So, that explained why I was getting insufficient privileges error.

Then, I looked at the reset code.

$query = "DELETE FROM $wpdb->options WHERE option_name LIKE 'gpp_%'";

It looked okay. gpp_ wasn’t hardcoded anywhere and the statement just looked okay. It deleted all instance starting with gpp_.

Then I tested another table prefix gpps_.

Oops! It deleted that too.

I tried another prefix : gppssssssss_.

My goodness! It deleted that too. Still getting the same error. The statement says specifically to just remove the ones matching gpp_ not gpps_ or gppssssssss_.

This left me thinking quite a lot and searching a lot. At one point I even thought LIKE and DELETE don’t go well together or if its deleting everything that started with g. But this wasn’t the case.

Then, one of my friends suggested if _% is some syntax in MySQL. It wasn’t. But I did find out that _ and % characters didn’t always play well with querying. In fact they were both used as wildcards. This was a bug with MySQL and perhaps it still is. So, the query was only understanding to delete all instances that started with gpp, not gpp_.

Solution

Finally, I found that in order to search for gpp_ in queries, you need to add a backslash otherwise it will just assume it as an escape character. So it needed to be gpp\_. Hence the query:

$query = "DELETE FROM $wpdb->options WHERE option_name LIKE 'gpp\_%'";

That solved the issue of just deleting all the instance that started with gpp_. But then, if someone somehow had a table prefix with gpp_, he is still going to be in trouble. So, I had to change the query to

$query = “DELETE FROM $wpdb->options WHERE option_name LIKE ‘gpp\_%’ AND option_name != ‘gpp_user_roles’”;

This saved the table data gpp_user_roles. So, no more  You do not have sufficient privileges to access this page error.

I hope my 2 days of brain jam and timeless research helped you if you are having the same problem. I am happy to have learnt one new thing although it would have been easier and quicker if I was a hardcore programmer.

Cheers!

Approximately a year ago, while I was starting to work with WordPress and trying out different plugins, I had encountered problems trying to integrate plugins that used MooTools and plugins that use jQuery. I had posted a possible solution in there as well. Here are solutions from jQuery site, if you want to know more.

So, after a year with playing around a lot of plugins that uses mootools / scriptaculous and other plugins that uses jQuery (which I prefer), I want to share one easy solution that I have found. I haven’t had any problems till now with this solution and I have been using and recommending to to all my themes.

You do not have to define and noConflict function as recommended by jQuery site. Simply, refrain from using $ as a shortcut to jQuery which means that you have to use jQuery in place of all $ used by your jQuery code. So, your code will look something like this:

jQuery(document).ready(function(){
   jQuery("div").hide();
});

I know its a bit tedious but it works well without having to take all the headaches of what is happening. So, while your jQuery plugin work perfectly, you can enjoy the features from other plugins using MooTools or other libraries.

Happy Thanksgiving to all. Once again, I would like to personally thank everyone for being a part of WPshoppe.

I have been working with WordPress themes for more than a year now and while most of the time, I am only using the default theme and changing the codes and styles as I want, one question has been circling my mind all this time. How do I enable comments in pages and not just posts?

First, I thought it was not possible. I have been getting quite many pingbacks and trackbacks on pages too but even though I approve them from my admin area, I don’t see anything on the page when I visit it. I never thought twice of what might be the cause. I always thought, well its not possible in pages.

Anyway, I just got a question from Kurt about this and a few times earlier. I never looked at the possibility but had this in mind, maybe the page doesn’t have comment template function call. I didn’t look at the code fully. Page.php was always what it was.

So, I just had some time and looked at page.php. Indeed, this was pretty simple. I compared with single.php and I didn’t see comment template call on page.php. I did a quick testing by putting this code:

<?php comments_template(); ?>

and saw the the page. Voila, there it was!

So, if anyone else is having this very problem of “how to enable comments on pages”, here is what you have to do. Put this code

<?php comments_template(); ?>

right before your closing content div. So, the code might look something like this:

<?php get_header(); ?>

<div id="content">
<?php // all page content goes here ?>
<?php comments_template(); ?>
</div>

<?php get_sidebar(); ?>
<?php get_footer(); ?>

I would love to know if you have any other ideas about how to enable comments on pages. This might not be so important since Pages aren’t there for commenting in the first place. I guess thats why the default themes (or most) doesn’t have this enabled.