The easiest way to have access to your variable in other files is to do exactly what Chip suggested, globalize the variable.
This is the same thing WordPress does to make global variables like $wpdb available in other files. I can already see you’re making calls to the global $wpdb variable in your class. You need to do the same thing.
When creating an instance in functions.php:
global $p;
$p = new Plans();
When referencing the global instance in header.php, footer.php, etc:
global $p;
$p->get_purchased_plans();
With this in mind, I want to clear up two things:
This is not a WordPress question
Yes, you’re using WordPress. And yes, you’re trying to figure out how to use a class within WordPress. But this question is in no way specific to WordPress. If you were building a website using just PHP (i.e. a single index.php file that includes header.php and footer.php and makes dynamic references) you’d still run into the same problem.
You’re question is about variable scoping, not about WordPress. Chip was 100% correct in calling this out earlier. I’m explaining it here rather than in a question so that you’ll explain why.
When you call $p = new Plans() in your functions.php file, you’re creating an instance of the Plans object and storing it in a local variable called $p. If that variable is defined within a function (as it should be), then that variable is local to that function. If it’s defined within a class, it’s local to that class.
Occasionally, you can accidentally define a variable in the global scope … this is a mistake made often by developers new to PHP or who are just getting started with object-oriented programming. It’s not a bad thing per se, but a bad habit to fall in to.
If you need access to your variable outside of the immediately local scope, always always always use the global keyword to make it available. That said, make sure you also name your global variable in such a way that name collision is minimized.
$p isn’t very unique. It’s very possible that a plugin (or WordPress itself for that matter) could redefine $p as something other than an instance of Plans() later down the road. That would break your theme … it should be avoided at all costs!
Something along the lines of $chifiliii_plans_p would be a better choice because I highly doubt any other system would also choose that name.
You’re doing it wrong
1 – Custom tables are BAD
It’s bad form to use custom tables in WordPress. There are very few cases where custom tables are warranted in the system, and in 6 years working with the platform I have only ever come across 1 or 2 reasons to have them.
If your theme is meant to be distributed, remember that some people won’t be able to use it. Several security consultants recommend that the user through which WordPress access the database be limited in its functionality – in many shared systems, it can’t create tables in the first place.
In multisite systems, you’re not just adding new tables for one site, you’re adding new tables for every site that activates your theme. This drastically increases the size of the database, which might be a problem for some users (though not all).
If you’re running custom queries directly against the database, you’re taking a lot of security concerns on your own shoulders. WordPress itself is pretty secure … unless you’re doing something wrong, it’s very difficult to open yourself up to malicious users who attempt SQL injection and other attacks against your system. If you’re running the queries yourself (outside of the WP_Query API), then you need to sanitize those queries to prevent malicious statements yourself.
As it is, WordPress has a fantastic Options API already.
WordPress also supports Custom Post Types for storing custom data.
Don’t reinvent the wheel … use the tools that are already in place to help you out.
2 – Don’t include functionality in themes
If you’ve got this much advanced functionality baked into your theme, you’re setting yourself up for failure. What happens if a user deactivates your theme? Simple … suddenly all of their custom data disappears.
It’s been said on this site many times: themes are meant to provide styling for WordPress. Plugins are meant to provide functionality. If you’re going to store custom data, do it through a plugin. Use the theme to style the presentation of that custom data.