You should never save default theme options to the database, especially on theme activation. That’s bad mojo, my friend.Learn to use proper defaults. I’m not sure how you’re saving options (Settings API or Theme Mods API), but both allow for defaults. Use them. Learn to love them. http://codex.wordpress.org/Function_Reference/get_option http://codex.wordpress.org/Function_Reference/get_theme_mod
I wanted to know if i created a WordPress theme and anyone could copy the php codes in it and make it their own and then sell it. Can that possibly happen ?
Yes, they can absolutely take it and sell it. All WordPress theme PHP code on TF is licensed under the GPL. By selling a theme here, you are explicitly granting the rights for people who receive your code to copy, modify, and distribute the code for free or a price. The only restriction they have is that they must also follow the license.
- You should read the license for yourself: http://www.gnu.org/licenses/gpl-2.0.html
- ThemeForest knowledgebase article for reference as well: http://support.envato.com/index.php?/Knowledgebase/Article/View/428
I don’t understand why we’re still talking about options frameworks. WordPress already has two really easy to use systems for theme settings.
1) Theme Customizer: https://codex.wordpress.org/Theme_Customization_API
Use this for visual stuff (colors, images, fonts, etc.).
2) Settings API: http://codex.wordpress.org/Settings_API
Use this for non-visual stuff, which shouldn’t be needed much for themes. The great thing about this existing framework is that it’s tested by 1,000s of developers and millions of users on a daily basis. You can add any options your mind can dream up using it. And, as a huge bonus, it will always fit in with the current WordPress admin design.
The best way to prefix these things is to actually use your theme folder name like so:
$themename_some_var // global variable themename_some_func() // function themename_some_hook // hook THEMENAME_SOME_CONSTANT // constant Themename_Some_Class // class theme-folder // textdomain themename-thumbnail // custom image size themename_meta // custom metadata _themename_meta // custom hidden metadata themename_some_option // custom options
Anything within the public namespace should be prefixed.
That’s the standard most WordPress theme/plugin authors should be following. Of course, if your theme name is pretty long, you might want to consider shortening your prefix.
Using a two-letter prefix, while mostly safe, can still lead to conflicts because it’s not very unique. It’s a heck of a lot better than no prefix though. If you’re using the same two-letter prefix across multiple themes, it’s especially not a good idea if that prefix deals with saving data (metadata, options, etc.) because data might be different between themes.
I just wish there was a convention for option panels.
There already is a convention for this. It’s called the WordPress Settings API. It’s stupid simple to use and allows you to input any type of form field you want. http://codex.wordpress.org/Settings_API
Do you think the theme customizer should be used for options that are non display related? It’s my opinion that it should not be used for options that update content, and only for style options.
Agreed. The customizer should only be used for settings related to display.
Now, the question becomes, “What are themes adding that are not related to display?” I have a few things in mind, but for the most part, anything unrelated to display doesn’t belong in a theme in the first place. I’m hoping the new submission requirements does away with this sort of stuff anyway.
Minifying your JS files is just good practice. I don’t see why you wouldn’t do it. You’d want to add both a minified and un-minified version of the files though. Just load the minified version.
As far as the license goes, are you going to distribute this code to anyone else? If not, you don’t need a license. Licenses are only really useful when distributing code. If you are distributing the code, then you’ll most likely need to put it under an open-source license. But, that depends on whether it would be considered a derivative work under copyright law.
Theme check is just one tool in a suite of tools, which gives a quick check of the theme review guidelines. The plugin actually runs through as many checks as it can (but not all) of the WordPress.org theme review guidelines. You should still manually check your theme files against the guidelines. http://make.wordpress.org/themes/guidelines/
You’ll definitely want to check against the Theme Unit Test Data. It has a variety of edge cases and commonly-overlooked things you should check for for front-end display. http://codex.wordpress.org/Theme_Unit_Test
You can also use Debogger, which is a neat tool for printing all debug info in the footer so you’re not searching around the page for debug info, which can sometimes be hidden by the theme’s design. http://wordpress.org/extend/plugins/debogger/
The Log Deprecated Notices plugin logs the usage of deprecated files, functions, and function arguments, and lets you know where the deprecated functionality is being used. http://wordpress.org/plugins/log-deprecated-notices/
The Monster Widget plugin will load all default WordPress widgets at once. It’s useful if your theme doesn’t overwrite the default WP widgets with custom ones. http://wordpress.org/plugins/monster-widget/
There’s also the WordPress Coding standards, which you should try to follow. http://codex.wordpress.org/WordPress_Coding_Standards
The most important thing is defining
true in your wp-config.php file so that debug info appears.
I’m sure I forgot something, but using the above should be a solid foundation to start from.
1) Absolutely not. That’s the worst experience you could ever offer a user. You’d be forcibly breaking their site for no reason at all.
You’ve already got half the solution to avoid errors in your above code. Check if a custom function exists before trying to use it. If the function exists, use it. If the function doesn’t exist, don’t try to use it; move along to the next thing.
Your theme should function correctly as a WordPress theme without any plugins installed.
2) Themes are for handling the design/presentation of data.
Shortcodes have nothing to do with that. Shortcodes are for wrapping up complex functionality into a simplified piece of code for users to enter into their post editor.
If the shortcode output needs additional styling to look good with your theme, then your theme should handle those additional styles.
I’ve asked numerous times for feedback on the Custom Content Portfolio plugin (linked above). I specifically created it for theme authors here on ThemeForest, but there has been little feedback on what features I should add to it to make your lives easier as theme authors.
The development of it is completely open on GitHub: https://github.com/justintadlock/custom-content-portfolio
Anyone is welcome to join the project and submit tickets. I’d like for it to be a well-rounded plugin for you guys and gals to use alongside your themes.