The minimum requirements to create a custom theme and how some of the new blocks work for the page creation have also been tweaked. Before 6.0, we needed to have the Gutenberg plugin installed and a block-based theme. Now, we only need a block-based theme.

You can start downloading an empty starter. Begin with this GitHub repo. This starter theme was made by Carolina Nymark. She has really great material on FSE. Check out her other work.

Open your favorite IDE and open your theme files. If you use localWP, you can spin up a local WordPress install. Now, add your theme and activate it.

We are going to build a simple home page for our theme, with a minimum amount of code. Thanks to theme.json and the Full Site Editor, let’s look at what we are going to build. This is a basic mockup I made with Figma:

We have a Header, a Footer, and some common sections that we will turn into Template Parts and  Block Patterns, as well as our colors, font sizes, and font family—all of which we are going to add to our theme.json.

theme.json

The first step, once we got our blank theme up and running, is to set our global styles. Let’s add some colors and font styles.

If it’s your first time working with theme.json, I encourage you, before you continue, to check the official documentation and get a grasp of what you can do.

Our color palette will look like this:

So on our theme.json, we do the following: on the settings object, we have our colors object. Let’s add our primary color:

This results in the generation of the CSS variable in the body of the website: --wp--preset--color--black: #D63E4B;.  Follow the same pattern and add the rest of the colors ( Secondary: #48655E, Tertiary: #59BDB4, Black: #333333, and White: #FFFFFF ).

This will generate our color palette. Go to your dashboard and open your Full Site Editor. Open the styles toolbar and click on the colors tab. There is our theme color palette:

We can also disable the default and custom colors by adding this  "defaultPalette": false,"custom":false, to the colors object.  Setting up our font sizes and styles is similar to how we add our colors. We will update the typography object on our theme file.

As with the colors, WordPress programmatically will create --wp--preset--font-family--helvetica-arial: Helvetica Neue, Helvetica, Arial, sans-serif; will generate the CSS Variable on the body of our website, and on the Full Site Editor, our typography is registered.

Follow the same pattern and add these sizes: 14, 18, 20, 24, 28, and 40px. When ready, save your theme.json file and open your Full Site Editor. Open the styles bar, and you will get your font family and font sizes.

Let’s take a look what theme.json has created for us. On your website, open the inspector tool. On the Styles Panel, take a look on your body element properties.

Excellent! We now have CSS variables with our values, globally available,  fonts and colors, and there are more settings for gradients, duotones, line-heights, borders, etc.

For the sake of this article, we are going to keep it simple. Lets’s take a look at how we can apply these styles to our elements and blocks.

First, we go back to our theme.json file on our IDE. We will add some properties to the styles, some spacing to our blocks, our typography, and default font sizes.

If we go back to our inspector tools, we can see the body has now our properties. You can use theme.json to adjust the styles to elements and blocks. Don’t forget to check the documentation to better understand what you can do with it.

Styling Blocks

Applying these styles to our blocks can also be done using the FSE editor. Open the styles tab, and let’s add some global styles to our buttons.

Here, we can set the typography, colors, and layout that the buttons will use. Follow the example below. Once you’re ready, hit save. It will let you know you’re adding a custom style. Save again.

So now, our default button is styled and looking like this on the backend/frontend. Using the inspector tool on our website, we can check the generated styles and our CSS Variables:

You can apply these styles to your blocks also on your theme.json. Following the same pattern, open your IDE,  and on the styles object:

Now that we get to know better theme.json ,  we can now focus on our Block Patterns.

Block Patterns

Our Hero, the Latest Post section, and our Call To Action section can be patterns. So, first of all, what are patterns?

Block Patterns are predefined block layouts available from the patterns tab of the block inserter. Once inserted into content, the blocks are ready for additional or modified content and configuration.

This feature in WordPress is super handy and it also has its own library. So, you can grab and use it, similar to how you add a theme or a plugin.

To build the Hero, we are going to use the cover block. With an inner group block, add a Heading (H1) a Paragraph, and a Button. Remember, we already set up all our styles via theme.json. All the settings can be added using the Full Site Editor. It should look similar to this:

Our pattern looks like the one on our mockup. There is no way we can add the patterns via the editor, similar to how we add template parts or reusable blocks.

You can use a plugin There are a few on the plugin repo  or you can create your own programmatically.

Once your block is ready, select the block. Open the sidebar options on the block options and select copy. This will copy the block markup. Go back to your IDE and open your  theme. Create a directory, name it patterns, add a new file hero.php and paste the markup.

Notice that we not only need to add the markup, but we also need to declare our pattern to let WordPress know what to do with this file. Similar to how we declare our templates, we declare the title, the slug, and categories. You can get more details on the official documentation. Click the Block Inserter, and there is our Hero Pattern:

Awesome! There is also one other pretty neat feature on theme.json. You can also declare patterns from the block pattern library. The patterns field is an array of pattern slugs and you can get the pattern slug from the URL in a single pattern view at the Pattern Directory. For example:

Sweet. Now, that we know how to create patterns, it is time to create the Latest Posts pattern. We are going to use the query loop block to show our three latest posts, with post image, post title, and the excerpt.

To get more on this super handy block, what do we do? Head to the official documentation.

Go ahead and do it yourself with what you learn in our previous example, but here is the gist in case you need it. I’m pretty sure you won’t. Our Latest Posts pattern looks like this:

Go ahead and create the final pattern. Again, you can build it yourself with what you learn so far. In case you need it, here is the gist for our final pattern.

Creating a Template

Now that we have our patterns, the next step will be to glue them to our templates. Open your Full Site Editor. Under templates, we have the index from our theme files.

We are going to create a new template by clicking on the Add New button. It will display a list of options that follows the WordPress Template Hierarchy. Select Front Page.

The first thing we are going to do is add our Template Parts, our Heading, and Footer. We have these parts already on our theme files, and most importantly, the Post Content Block.

Following our mockup design, click on the Block Inserter. On Patterns, add our own. It will look like this:

Now, we need to add some content to our homepage for the Subject of the page. Open a page and add your content. Copy what we have on the mockup.

Once that is ready, save it. Go to the dashboard, click on Settings >  Reading > then select your new page as Homepage. Save it and open your website.

We are getting closer… really close. I will say, we need to add a few styles here and there, but we manage to get really close to the mockup without a single line of CSS.

With the help of theme.json we add global styles, colors, fonts. And with the help of the Full Site Editor and the Block Patterns, we create our template and some patterns that we can use across our site—not only when templating, but also when creating posts and pages.

So far, we have just created the Front Page template, but is up to you to create the rest of the templates needed for your theme.

Exporting My Theme

Yes, you can build themes locally with the help of the Full Site Editor and also export it and ship it. Since we are creating a theme, before exporting, we still need to enqueue some custom styles that we need for our theme.

From here, there are many options. You can add wp-scripts or any task runner to your theme. For now, I will only enqueue a basic stylesheet.

Back to your IDE. Create a new directory for our styles. Name it css. Create a CSS file (named as you like) and paste these styles. To enqueue styles on a block-based theme, use the traditional way and add it to your theme’s functions.php file.

Now, here is our theme with the styles. Pretty good.

Great! We just completed our task, created our landing page, and it is also responsive by default. Now, let’s export our theme.

On the Full Site Editor, click on the three dots on the top bar to open the settings bar. Click on the option to export your site:

This will generate a .zip file ready to ship. Go ahead and add your theme and try it out. Here is the repo of the generated theme.

This is just a basic example of what you can do with the new Full Site Editor. I’m really excited about this new way of building themes. There are a lot of documentation, tutorials, and humans that are doing really great things with WordPress.

Thank you for taking the time to read this article. See you next time!

The post Let’s Create an FSE Theme appeared first on WebDevStudios.

In my private time, I’ve been building a starter theme from scratch to better educate myself about what is required by WordPress to build a theme-repo-approved theme but also to make my own informed decisions based on what others are doing, how people typically use the internet, and what of WordPress core feels antiquated.

I started writing this blog post to try and build a custom theme from scratch, but that proved too problematic for a few reasons. The time commitment wasn’t small. Any theme I built would require more than just one blog post and there’s a world of information out there to help you on your way already. Also, before any opinionated decisions had been made, the outcome was essentially any other theme out there already. The biggest reasons I thought I’d circle back and rethink this post was because a lot of those opinionated decisions I was making were very much outside of what is traditionally accepted and/or removes items required to be in the theme repo.

There are plenty of articles that will walk you step-by-step in building a theme, but I’m not going to do that because I think it’s important for aspiring developers to take some general knowledge and explore and implement on their own, really learn by doing rather than learn by emulation. So instead of building a theme from scratch, let’s keep it high-level and talk about what is required, what’s new in 2019, and some of the ways I think we could clean up WordPress for the frontend and for users.

For Starters

I’m going to assume you’ve setup a WordPress install already.

When building a theme, you can reference the WordPress codex for Theme Development and the Anatomy Of A WordPress Theme cheat sheet so that you can ensure you’re using the proper coding standards and anticipated elements. This will give you an idea of what WordPress would be expecting.

We’ll set up a new theme folder inside the wp-content > themes directory in which we’ll put all of our files. Name it whatever you’d like, but that folder name should match your theme’s text domain.

To function, a theme really only needs two things: a style.css with your theme details and an index.php file. You can learn more about the required files from WordPress directly here in which they also suggest comments.php and screenshots.php as requirements. Really, aside from the theme information in the style sheet, you don’t need any markup for WordPress to successfully activate the theme, though it won’t do anything at this point.

Success!

From there you start adding template files and extend your new theme. Those files might include:

• 404.php — handles our content not found
• comments.php — handles your commenting
• footer.php — the ending place for your theme, closes all of our tags
• functions.php — adds some default setup for our theme
• header.php — opens our tags and handles meta data and navigation elements
• index.php — the default home or blog river template; this will also handle our archives
• page.php — the page template
• screenshot.png — your 1200 x 900 px screenshot for the theme dashboard.
• single.php — the singular post template
• style.css — styles our theme, but also contains the theme description and info

These would give you a pretty bare-boned and well-rounded WordPress theme. Take a look at any of your favorite themes to make decisions about how those templates should look and what content and markup those might include.

Moving On

From there, your theme requires several functions and declarations to add support for various things. The easiest place to start is inside the functions.php and set up our _theme_setup function which hooks after_setup_theme action. This gives us the ability register default functionality, add theme support of certain things, and allows child themes to overwrite any of your theme functionality.

So let’s go through that setup briskly. We’ll take a look at the Twenty Nineteen theme setup since it’s a WordPress core theme. We’re setting up support for various site functionality out of the box. We’ll define our text domain for translations, set up RSS feed support and lets WordPress handle the meta title. It goes on to add support of post thumbnails, custom navigation areas and output valid html5 markup for various elements, editor styles and widgets.

WordPress 5.0+

The main elements to take note of here are the addition, since the release of 5.0 and the formerly-known Gutenberg framework, is the theme support for a few items to enhance this new editor for your theme.

add_theme_support( 'wp-block-styles' ); which allows your theme to add to the default set of core block styles.

add_theme_support( 'responsive-embeds' ); which allows embedded media to retain its aspect ratio.

add_theme_support( 'dark-editor-style' ); if your theme has a dark background, you can turn on the dark editor styles to help match your front end more visually. Typically utilized with add_theme_support( 'editor-styles' );.

add_theme_support( 'align-wide' ); offers the ability to add class names to the image wrapper for those elements that offer wide or full-width images.

Without this feature, those elements aren’t available in the editor.

add_theme_support( 'editor-font-sizes', array() ); sets the editor font sizes which correspond to editor styles and are available within the block settings where applicable. The defaults are the same as what’s defined in the theme here, but any font sizes or uses could be added in your custom array.

add_theme_support( 'editor-color-palette', array() ); does the same thing, setting your theme’s main color palette.

The default, sans this function, looks like this:

You can read more about those in the Gutenberg Handbook here, but the point is that with new editor comes new support that we’ve not seen before and, from my internet deep dive, hasn’t really gotten the exposure it deserves, even if the new editor has only been met with minimal praise thus far.

Planning Your New Theme

This next bit is about user expectations. There are a couple different types of themes out there—those that expect the users to have a specific setup and utilize the theme in a specific way (a photographer’s portfolio, for example) or those that are more general and are intended to be used the way WordPress was intended to be used, as a standard blog. So, it’s important to have a game plan to determine how involved you’ll need to be in your new theme development project.

Here’s where I went down a rabbit hole: I have certain assumptions about, based on internet research and practical experience, how users typically use a website vs what typically comes with a default WordPress theme. WordPress makes its own assumptions about how users utilize their themes and websites. It is my opinion that these assumptions and reality don’t align, but that doesn’t mean that we shouldn’t at least look at the industry standard before making changes. Learn the rules before breaking them.

General Assumptions

I’ve mentioned many times in the past that every WordPress theme since Twenty Ten is essentially the same as each that proceeded it. Of course, functions were added and deprecated and standards changed to accommodate the changing internet landscape, but for the most part the core guts of the default themes have been more or less the same. It could be argued that the Twenty Nineteen theme is the most different but its core guts are still essentially the same. It’s the biggest area of note is the absence of the sidebar.php template which would be a bit more, but all of its content has just been moved to the footer.

In nine years, the internet, the way people use the internet, and the expectation of its users have changed quite drastically, though the WordPress Core themes have not.

I’m not saying that WordPress is wrong. They do set the standard and their goal has typically been to build something for the majority which their themes do accomplish. I’m just saying that when building a new theme, we might think about users a bit more specifically.

My Personal Assumptions

My assumptions about what a website, and as such a theme, should be can be summed up in three words: simple, clean, and focused. With the inundation of media and content at every waking hour, our attention is divided too thinly to make any real impact on the user if it requires work to filter through all of your content without some help.

Simple

For a basic website, unless you’re an eCommerce store, you don’t need drop downs or more than a few pages. There’s a lot of default information that isn’t typically relevant for most users either, such as post author, tags, number of comments, etc. A user probably only really needs to know when a post was published and maybe in which category it was published. Unless your website has carved out a section specific to authors and their content, the author is unimportant. They’ve come to your website because of your brand or already understand that the content is of a singular entity.

Clean

Clean, like simple, is about keeping things concise. But in this case, ‘clean’ references your design and layout. If users can’t find what they’re looking for, you’re probably overthinking your design and muddying the layout waters. Think of a website like a set of step-by-step instructions.

1. Find page
2. Click link
3. Read article
4. Sign up
5. Repeat

If at any point users get distracted or lost, your mission isn’t clear enough and needs to be readdressed.

Focused

Your website and your theme need focus. They have a goal in mind. The goal can be as simple as, “This is JUST a blog,” to “People NEED to see the most recent blog post,” to “Images are the MOST important thing.” Your intended focus will determine the structure of your website. The main point here is that if your theme is intended to focus the user’s eye and content in a certain place, make sure that your execution is clear. And don’t try to over complicate that goal.

As We Continue

If I had my druthers, I would completely remove things from WordPress Core. But I don’t want to maintain my own fork of WordPress; and for all its flaws, it’s pretty solid as it is. This means we need to support things in our theme even if we don’t feel they’re necessary, specifically if you plan on submitting your theme to the Theme Repo. I personally don’t find widgets or certain archive templates necessary for most people, and I certainly have feelings about WordPress comments, but I still support their functionality because I am not every person.

Be as opinionated as you want and push those boundaries, but know your audience.

The post Building a WordPress Theme: Things to Consider in 2019 (And Beyond) appeared first on WebDevStudios.

At WebDevStudios, we decided to create a child theme for a recent client project. Customizing Storefront directly would make it impossible to upgrade for new features and bug fixes. Any changes would be overwritten during the upgrade process. By creating a child theme, we have the ability to upgrade the parent theme (Storefront) for access to new features and bug fixes.

Throughout the article, when I refer to parent theme, it’s Storefront.

Folder Structure

A child theme is basically a blank WordPress theme—it becomes a child theme when you define the parent theme in the “Template” param in the header block of a child theme’s style.css file.

For example:

View the code on Gist.

Notice how we have defined “storefront” in the template param of the style.css header block. The template param should equal the folder name of the parent theme. In this case, our parent theme’s folder name is storefront.

This flexibility of a blank WordPress theme allows us to set up this project similar to the starter theme that we use for all our internal projects.

The following folder structure is inspired by our starter theme wd_s. For this project, I have simplified the folder structure, especially the sass folder, since we will be mainly using Storefront’s styles and doing little customizations to it.

Folder Structure:

• assets
  • images
    • sprites
    • svg
    • svg-icons
  • sass
    • style.scss
  • scripts
    • concat (individual JavaScript files in this folder are compiled into project.js file).
• inc
• languages
• template-parts

Build Tools

We will be using Gulp setup from our starter theme wd_s. Gulp will will perform the following tasks:

• Compiles Sass files into CSS (from sass folder)
• Vendor prefixes CSS automatically
• Minifies JS files (from scripts folder)
• Compiles JS files from concat folder
• Minifies images inside images folder
• Generates sprite file & Sass mixins automatically from images dropped in sprites folder
• Compiles and minifies SVG icons dropped into svg and svg-icons folder
• Generates .pot file for il8n strings based on theme’s text-domain
• Automatically runs the build process on file changes
• Immediately preview changes in the browser using BrowserSync
• Runs Sass and JavaScript lint in a task to help identify coding errors

To get started, install Gulp globally:

npm install -g gulp

Create a package.json file in the root folder of your theme with the following contents: the package.json file is used to define npm packages that are used by Gulp to execute the build process.

View the code on Gist.

Run npm install to install all the packages defined in the package.json folder.

Make sure to add thenode_modules folder to the .gitignore file. We don’t want to version control node_modules.

Next, we need to define the Gulp tasks and how to run each of them. Create a gulpfile.js file in the root folder of the child theme:

View the code on Gist.

1. Edit _s on line 292, 293 and 295 with your theme’s text-domain. This will be used to generate the il8n pot file.
2. To setup BrowserSync, edit _s.test on line 361 with your local development URL. Access BrowserSync by adding port 3000 to the end of the development URL.

After the above setup is complete:

Running gulp in the terminal after the setup is complete will generate sprites and pot file. Compile and minify icons. Minify images. Compile and minify stylesheet and JavaScript.

Running gulp watch in the terminal will continuously look for changes in the PHP files and files in the assets directory. Any changes that you make to those files will not require a browser refresh on the development URL. Gulp will live stream the changes to the development URL with the help of BrowserSync.

During the development process, it is highly recommended to run gulp watch.

Running gulp lint will run JavaScript and Sass lint.

Coding Standards

PHP Coding Standards

For PHP code, we use our own set of coding standards extended from WordPress Coding Standards. PHPCS is the tool used to run against these rules. You can configure your editor to run through these rules.

WordPress Coding Standards

WDS Coding Standards

JavaScript Coding Standards

We use WordPress JavaScript coding standards and extend it to adapt to our way of writing code. These rules will be tested against whenever you run gulp lint. You can configure your editor to run ESLint tests, which is recommended and makes it easy to see errors and warnings as you write code.

WordPress ESLint Coding Standards

WebDevStudios ESLint Coding Standards

Sass Lint

We use Sass to write all CSS. Like ESLint, the rules are defined in a sass-lint file and will be tested against whenever you run gulp lint. Just like ESLint, you can configure your editor to run sass-lint which is recommended and makes it easy to see errors and warnings as you write code.

WebDevStudios Sass Lint Rules

This ends a quick rundown on how we set up Storefront for our client projects. Having build tools and coding standards added to our projects help us write clean and maintainable code. How do you setup your Storefront projects?

The post Modern Theme Development with Storefront appeared first on WebDevStudios.

Commercial Themes / Plugins

When I was a freelancer, I used to think commercial themes were the bomb. They had everything: sliders, tons of short-codes, page templates, page builders, the works… However, the more I learned about WordPress, I learned the first and major problem of commercial themes is their ability to be extended. The objective of a business is to retain it’s customers, and what’s the easiest way to do that? Do not make your theme developer friendly!

Nowadays when a developer sees a commercial theme, he’s going to do one of three things: make the theme his own so he can write the code to his specifications, make a child theme and risk spending tons of extra hours fixing the core theme anyhow, or spend hours on end reading the documentation (if any) on the theme to set it up how the client wants it, if that’s even possible.

I could go on and on about commercial themes, but in short, most of the time a theme from these top sellers are not extendable. There are usually very little to no filters/actions beyond what WordPress already offers. Sometimes it’s just an oversight on the developer’s part, other times it may be a business decision which I understand, but I believe in ALWAYS writing your code as if another developer will need to add to it or take away from it later.

I want to conclude this section in saying not all commercial themes are bad, just do your research before you decide “This has everything, I’m gonna buy it!”. Do you really need thirteen sliders?

The WordPress Way

WordPress has two very nifty methods, which I’m sure you’ve used their counterparts, add_action and add_filter, which are do_action and apply_filters. So many times when working with a theme have I wished a filter was used, but most of the time it’s not.

Most of the time, you can create a child theme, and overwrite the template you’re working on, adding in the filter you need. However, if the filter/action you want to add resides in the functions file (functions.php) you have to literally replace all functions with your own, and replace all calls to those functions everywhere they’re called, in turn bringing more files into your child theme. Before you know it, you’re in a spider web of function calls. I’ve been there. Plugins are double hard to muck with, it’s even harder to extend a plugin, and you’re absolutely limited to what the plugin developer has allowed you to modify.

 Hooks are provided by WordPress to allow your plugin to ‘hook into’ the rest of WordPress; that is, to call functions in your plugin at specific times, and thereby set your plugin in motion… – WordPress.org

You are usually using these hooks to edit the core functionality of WordPress in certain circumstances, but, these hooks aren’t just for hooking into things. They’re also available so other plugins can hook into your content.

What to use, and when to use it!

Always think of the future use of your plugin or theme. If it’s a form, maybe a user may want to add more fields later down the road or maybe some sort of authentication method that a developer will need to hook into. There’s absolutely no reason you cannot hook into it and provide data related to the function/display call.

I personally use the do_action method sparingly when I create themes or plugins (plugins mainly because I’m no designer). My rule is that if a user wants to output content that is displayed and shouldn’t need to edit content, arguments, or some other setting in the current context, then I use an action!

The apply_filters method, on the other hand, is always in my back pocket. This is really handy for allowing another developer to overwrite output, modify custom queries, and tons more things. My rule here is to filter all the things…not kidding. If I’m running a custom post type query somewhere on the site, it has a filter; if I’m outputting stuff to the front-end, it will have a filter. Though there are special cases that I don’t use filters such as option panels and other settings related pages. If you’re using CMB2 for this, that’s handled for you…you are using CMB2, right?

Conclusion

The above methods are not the be-all, end-all methods of extending plugins and themes. PHP itself has some very nifty things up its sleeve such as Class Extensions and Implementations, or, if you’re the stickler for formatting, but still want extendability, Abstract Classes is the way to go. (Thanks to Ben for that one!)

Bottom line: You have zero reasons for not making your plugin or theme developer friendly. Yeah, sure, we can extend your theme to no end, but if it’s a pain in the rear, we will more than likely fork your theme, and make it our own. And when it comes to plugins, please, I’m begging you, please make them developer friendly! Think of the future people, please?

If you have your own methods to make a theme or plugin is extendable please do share. I love knowledge–you can never have too much of it!

The post Making Developer-Friendly Themes and Plugins appeared first on WebDevStudios.

Why StartBox?

It actually makes perfect sense for us. We wanted to work on a framework that we could help shape the future of. Not only is StartBox an amazing theme framework, but it’s also an established name in the community. Brian has built a great product and we only want to help make it even better.

StartBox is also our first major push into the commercial WordPress space. We’ve been trying for years to build and release commercial products, but it’s a huge challenge when there is no revenue being generated. Our primary focus has always been on our client work, which made it very hard to dedicate time and resources to a commercial offering. StartBox is a turnkey product and already has 9 premium child themes on the market.

What’s Changing?

The biggest change you’ll see is more active development around StartBox. We now have an entire team dedicated to contributing to StartBox core and creating custom child themes and plugins designed specifically for StartBox.

Brian Richards will remain the project lead and help us shape the roadmap for the future of StartBox. The framework will also remain 100% freely available on Github and of course StartBox will always be 100% GPL.

If you want to get involved you can contribute to StartBox on Github, follow StartBox on Twitter @wpstartbox, and subscribe to the StartBox blog for updates and news announcements.

This is a really exciting time for WDS! Stay tuned, because we have even MORE exciting announcements coming this month.

The post StartBox finds a new home with WebDevStudios appeared first on WebDevStudios.

Thesis is a powerful WordPress Theme that gives users very flexible tools for customizing your WordPress powered website. With features including custom RSS feed link, customizable navigation menu, and search engine optimization right out of the box, it’s easy to see why Thesis is so popular among WordPress themes.

Thesis can be extended to execute any custom written code needed. With its large array of functions and hooks, you can create virtually any modification to Thesis and WordPress powered websites.

Not only is Thesis a solid WordPress theme, but they also keep their design updated. The most recent update, version 1.3.2, was released on November 13th, 2008. That’s just four days before this post.

Below is a list of very valuable Thesis references and hooks for website developers and designers.

Thesis References and Hooks

Thesis Support Forums
Thesis Hook Reference List
Default Hook Usage in Thesis

WordPress also has a wide range of functions and hooks that can also be used to create custom plugins and widgets.

WordPress Function and Hook Reference

WordPress Codex Function Reference
WordPress Hooks Database
WordPress Hooks Directory

WebDevStudios.com can help you extend your Thesis WordPress theme to handle any task or functionality. We also have very talented graphic designers who specialize in Thesis styling and theming using CSS.

The post WordPress Thesis Theme Support and Reference List appeared first on WebDevStudios.