SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Theme approval guidelines [Outdated]

Started by Gwenwyfar, July 08, 2018, 10:25:29 AM

Previous topic - Next topic


So you want to make a theme (or you already made one!) and want to submit it to the theme site. All themes submitted to the theme site will first go through a review process before they receive an approved status and are shown in searches. If a problem is found during the review, you will be asked to fix it before proceeding. Here's how to get your theme ready:

Theme guidelines
Take some time to get acquainted with the guidelines outlined here. Your theme will have to comply with them.

Required folders
  • css: This folder should have all your custom css files.
  • images: Images folder containing all images used by your theme.
  • scripts: This is where you can add theme.js to add any custom js, or you may add your own files.
  • languages: This should contain the Settings.english.php file, which is where you can edit the description for your theme. You can include other language files for your theme here, but english should always be available. If you are using any custom strings, these can be added in ThemeStrings.english.php. This file will be loaded when ['require_theme_strings'] is set to true.

Required files
  • theme_info.xml: This file contains data about your theme. You can download a template below. (More about theme_info.xml)
  • license.txt: This file should contain license information for your theme, and any other licensed work you have used in your theme (ex: images). For help with choosing a license, see the wiki page on Customization Licenses and this topic. You can use any license you want to, or write your own license.
  • images/thumbnail.gif: A preview thumbnail of your theme. Preferably, you should use the same size as the default thumbnail.
  • index.php: A copy of the default file.

And finally, once you have made your theme, time to package it! For the theme to install correctly, you should package only the root files and folders. Compress it into a .zip or .tar.gz file and it's ready to go. If you package is inside a main folder, your theme will not work.

To submit your theme, simply go to the theme site and post a new theme.

If you have any questions about the approval process or about the guidelines, you can ask here or send a PM to someone in the customization team.
"It is impossible to communicate with one that does not wish to communicate"


Ok, I am asking here. :D

I know traditionally we are supposed to have all HTML validate for theme submissions, but these days we have all sorts of HTML5 grooviness available.

This groovy new stuff doesn't validate with the 2.0.x transitional doctype, but it does actually work, and it does give theme authors and users some handy new things. Just as one obvious example: placeholder text for inputs. It's useful, and it won't break anything, but it's not actually valid HTML if the doctype is transitional.   

So, are the infamous Purple Peeps cool with theme authors deliberating breaking 2.0.x validation to incorporate HTML5 elements that will not bork functionality or layout, and will provide useful enhancements for users?

Diego Andrés

Just change the doctype to html5 in index.template.php
would be !DOCTYPE html I think

SMF Tricks - Free & Premium Responsive Themes for SMF.


Lol. There's a problem with that. A lot of the HTML for 2.0.x doesn't validate with an HTML5 doctype. ;)

Diego Andrés

That's odd because there's already many html5 themes on the theme site.
I remember a few years ago I didn't encounter any validation errors while using html5, not sure

SMF Tricks - Free & Premium Responsive Themes for SMF.


Really? I would have thought there would be heaps. Not so much in the actual custom template provided with a theme, because the theme author can always sort those out for validation, but the rest of the 2.0.x templating contains heaps of stuff that doesn't validate with HTML5.

Mind you it won't actually break anything, but it'll send a validator bonkers if you take a trip around 2.0.x while running an HTML5 doctype in index.template.php. :D

But if the team is only worried about templates actually provided with a theme, that's generally pretty easy to sort.


QuoteOk, I am asking here.
I didn't lock this topic for a reason ;)

2.0 has lots of inline styles and <b> and <i> tags which are bad practice, but other than that I can't think of anything that would not validade in HTML5. <input/> and <br/> are still valid for example, although you can use those without the / in HTML5.

But yeah, it's a bit unfair to ask too much for 2.0 themes when the base theme is a mess. At least while I was in the team, 2.1 approvals were a bit stricter because of that (2.1 has had most inline styles done for, for example).
"It is impossible to communicate with one that does not wish to communicate"


<link rel="stylesheet" type="text/css" href="" />
<link rel="stylesheet" type="text/css" href="" />
<script type="text/javascript" src=""></script>
<script type="text/javascript" src=""></script>

OK, start of the source code for this particular board. All of those will break validation with an HTML5 doctype. ;)

I went through this recently with TP (see: etc).

Now none of those will break functionality, which to my mind is the important thing but technically they are invalid in HTML5.


Trying to validate those gives warnings, but not errors.
"It is impossible to communicate with one that does not wish to communicate"


Ok, if you're not worried about warnings that's fine. What about charset? Charset is declared all through 2.0.x in a stack of places, and the only charset that will validate in HTML5 is utf-8. So every time a form or whatever pops up with another charset declared, that will conflict with the HTML5 doctype in index.template.php.

Screeny demonstration. :)

ETA: I know what you'll probably say. That everyone who wants to use a theme with an HTML5 doctype can do a complete utf-8 conversion on their forum. They're not going to though. They'll just install the theme and use it. ;)


That's a good point. I think the instance on that has been that mod/theme authors can pick what they are supporting, to a (sane) point. They're already breaking core support to older browsers, for example, or they might require something not all users have. It's not something that has stopped themes getting approved, but I'm not sure how relevant this is being that utf-8 is the way to go, going forward. That's for the current customization team to decide.
"It is impossible to communicate with one that does not wish to communicate"


You needn't worry about the charset @Antechinus, nothing you can do about it.
Checkout My Themes:

Potato  •  Ackerman  •  SunRise  •  NightBreeze


Ok, another question. :)

Is there any issue with including LGPL icons in an SMF theme? I mean apart from linking to the license and the author's site, which they (KDE/Oxygen) require as part of their conditions.

I'm just wondering if there's any conflict with SMF's BSD license, or if I want the theme itself to be under the ISC license.

(I vaguely recall there being all sorts of kerfuffles when trying to find icon sets compatible with 2.0.x and 2.1 Alpha).

Diego Andrés

Just linking them in the description is enough along with the license I'd assume

SMF Tricks - Free & Premium Responsive Themes for SMF.


Correct, that's absolutely the case. You probably should go and include a readme.txt file somewhere outlining it and a copy of the LICENSE file as well (but with an edit to the top to say what it applies to) just to be on the safe side.

Including LGPL works into SMF core is a different battle to including them into a theme you are distributing separately from the core, as if part of the core the assumption would be that it is all BSD, including the parts that aren't.


Sounds reasonable. At the moment it's only a high-definition sprite for the quickbuttons strip. What I was thinking of doing was echoing that sprite to the credits page, along with a blurb thanking them for the icons and linking to their site and to the license. Might possibly throw a discrete credits link into the footer too. That should keep everyone happy.


Credits page would be neat, credits link into the footer is above and beyond.

Unfortunately 2.0's credits page has no hook, which would make this sort of thing trivial to do.


Well the credits page has no actual way of getting to it if you don't have admin access. You can throw a direct url at your address bar if you happen to know how to do that, but most people won't know. So one more word/link, in the footer is not all that bonkers. Wouldn't bother me.

I have already edited Admin.template.php anyway, so throwing a bit more on the end doesn't bother me in this case. I suppose you could throw a hook in via a mod, if anyone wants to do that.


QuoteWell the credits page has no actual way of getting to it if you don't have admin access.

Except for action=credits which is also linked in the footer and is visible to all users - the SMF 2.0.15 link in the footer is the credits link, SMF (C) 201x is a link to the SMF licence, and Simple Machines is a link here. Has been that way for years.

2.1 has multiple ways of doing this, it has both a hook and package-info.xml can directly do things (not sure about themes, but definitely can for mods)