Now that you know why Thesis 2.1 is perfect for Web Design professionals, let’s talk about the Thesis 2.1 file structure. If I’d had time I would have discussed this topic in the DIY website Builders seminar.
Thesis 2.1 Resources – Diagram of the File Structure
So we’re going to talk about the Thesis 2.1 file structure and I have a resource for you here on the main link, resources articles. I’ve created a bunch of downloadable resources for you for Thesis 2.1. One of those resources is this diagram of the WordPress Thesis 2 file structure. And so if we click on that, it takes you over to this cool, little diagram here which shows you the file structure.
Why it’s Important to Understand the Structure
Understanding the file structure is really important for when we start creating skins using the dev tools box and when copying skins, exporting skins and exporting skeleton data. It also turns out, it’s very important to understand when troubleshooting.
It’s not like normal WordPress which is wp admin, wp content. Inside of wp content, you’ve got plugins and themes. And inside of themes, you would have your theme, thesis. Well, Thesis 2.1 places its core files there. And so you do have a Thesis folder but you also have a Thesis folder directly under wp content. Now this Thesis folder is called the Thesis user files folder. And Thesis places core files over here and user files here. And inside of that user files folder should be a folder for boxes, a folder for packages and a folder for skins.
I’m helping somebody on the forum right now troubleshoot a problem that they’re having on their site. And I suspect that this boxes, packages and skins folder has been deleted. And so they’ve got a Thesis folder here but they don’t have these folders inside of it. Well, without these user folders, the main Thesis chokes. So it’s necessary that this folder structure still be maintained.
Layout of the Structure
As I said, you do have a Thesis folder but you also have a Thesis folder directly under wp content. So you’ve got your wp content/thesis folder inside your boxes, packages and skins. Also inside of that is a file called master php. And this is a file that you can use to edit, to add php to your site.
And then inside of this skins, at the very least, you have Thesis Classic and actually, it’s going to be classic R. But nevertheless, you have Thesis Classic and Thesis blank on a regular Thesis installation. And inside of Thesis Classic and essentially, inside of any finished skin, you have an images folder, css.css file, a custom.php file, a screenshot. The screenshot is optional but you’re going to want it.
Description of What the Files Do
The css.css is a file that is automatically generated every time you save your design options, right? It gets regenerated in whole. So you don’t want to ever change it physically. This is not a place where you would change your css physically. You’re going to change your css inside the dashboard, either in custom css or skin css.
Custom php is another file where you can put your own custom php in. Screenshot png is of course, a screenshot that shows up in the Skin Manager.
Seed php is the file that is generated when you export a skin that sets the skin’s defaults. So that when you go back and click on the button that says ‘restore defaults in the skin manager’, it goes to seed php to understand what those defaults are and to refresh those. Now seed php is not something that you create. Seed php is something that is created at the point at which you export a skin from the dev tools box.
Skin php is the main php file for the skin and it contains the real skin code. And this is the file structure that you’re going to be working with.
Methodology for Using the User Files
Now, I say all that because I want to propose a methodology for you for those user files. Remember, we have 3 different sets of php user files. We have master php. We have custom php and we have skin php.
As a web designer, you want to use master php for programming that should be independent of the skin. That is, programming that you want to work no matter which skin is activated. You may be activating one skin or activating another skin but you still want the functionality of this code to be working no matter which skin is activated.
And in that case, we’re talking about stuff like registering custom post types and registering custom taxonomies, something that you don’t want to stop working just because you switched skins.
Now it might even be WordPress best practice to actually create a plugin for that and to include your custom taxonomy and custom post type registration so that it’s not dependent upon the Thesis theme as well. But as long as you don’t mind that stuff being theme-dependent, that is dependent on being in Thesis, then you would use master php for this.
You’re not going to use master php for something that’s only going to happen in a single skin because master php fires no matter what skin is being used.
You’ll use custom php for programming that is dependent on the skin. And I’m going to show you an example of that near the end of the session today. But if you’ve got a piece of programming that you want to stick into your skin and you only want it in that skin and if somebody activates another skin, you don’t want it to be active then you would use custom php for that as long as you are not the skin developer.
Custom php is intended for the end user of the skin. So if you are developing a site based on Thesis Classic Responsive then you would use custom php for any custom code that you added to the site. But if you’ve developed your own skin that you’re distributing, this is not where you’re going to write your php. This is where your end user can write their php.
And the reason for this is that when a skin is updated, it does not overwrite custom php during the update process. So if you’re working in Thesis Classic Responsive for example, and you have custom code that you want applied inside that skin, if you put it in skin php, it’s going to be thrown away when classic responsive gets updated. So you don’t want to put it in there. You want to put it inside of custom php.
The reverse is also the case though. If you are the skin developer then you want to use skin php for programming that’s dependent on your skin. Because that way, in any kind of automatic upgrade process, skin php is overwritten. And so you can automatically change the code that’s in skin php simply by upgrading the skin.
Difference Between skin.php and custom.php
That’s really the difference between skin php and custom php. Skin php gets overwritten during an upgrade and custom php does not. And since you are the skin developer, if you’re not the skin developer, you’re not in control of the upgrade process. And if you are the skin developer, you are in control of the upgrade process and it just depends on where you are in this thing to… that’s what makes the decision whether or not you should be using skin php or custom php.
Master php is never overwritten which is one of the reasons why it shouldn’t be skin dependent. The only code that goes into master php is code that has nothing to do with the skin itself.