Just to be super clear, as long as there’s a prefix, everyone’s good? Even if it’s the author’s name in some form?
Hey Aligatorstudio,
It certainly couldn’t hurt! All the reviewers are aware of this, but I guess we may not immediately know whether a framework is being used or not, so pointing it out would help.
If you don’t point it out and your theme does end up getting soft-rejected, you can obviously let the reviewer know at that point, but of course that is an extra step!
1 Like
Thanks to you too @mad_dog! 
Hi BonfireThemes,
Well it’s fine if it’s the theme name or the framework name (which will obviously be related to the author’s name if it’s their own framework). If it’s just the author name, not in the context of a framework, then it may not be accepted, so probably safer to use one of those.
Hi Stephen.
I have the habit of developing themes from one to the next in order to constantly improve on the code base. I’d like to use “bonfire”, “bnfr” or the like as a prefix and not be forced to change all instances of it with every theme as it just creates extra work. Are those examples allowed?
If not, what do you see as the difference between using the theme name and using an author name in some form? I guess I’m hunting for the reasoning behind allowing theme names as prefixes (even if they’re common words) but not some variation of an author name.
Thanks.
Just to make sure as every replay has this mentioned - ‘themename_’
Is it fine if prefix is combination of both - author name and theme name (not complete theme name)?
Say if theme name : Modern
Author name : KlassicThemes
Prefix: ktmdrn
Guys, this both will work now.
What about text-domains ?
I got a theme rejected, because I was using a text-domain “village”, which we’re using in all our themes ( we’re ThemeVillage ). Does it really have to be theme specific or did this change along with prefixing ?
1 Like
Is something wrong with using namespaces / autoloader ?
This way you could even use the most generic class names and only change the namespace for every new product. It’s recommended PSR-4 practice.
1 Like
This is interesting
I wanted to touch on this topic a bit since my article was mentioned several times.
For the framework (or library) question, you should absolutely keep the same prefix across multiple themes. Otherwise, it kind of defeats the purpose of using a framework. The prefix should be unique to your framework. However, you should help your reviewers out. If you’re using a framework, package it all up into a single folder within your theme. Don’t have “framework functions” all over the place. Organization is one of the cornerstones of great programming.
Don’t just copy your functions from one theme to the next and say, “I’m using a framework.” That’s not a framework. Either you’re using one or you’re not.
Now, custom functions that are not a part of your framework should be prefixed with the theme name or theme + author name. It should be clear which functions are a part of the framework and which functions are specific to that theme.
It doesn’t really matter in the grand scheme of things what the prefix is. What matters is that you’re using one, it’s relatively unique, and that you use it consistently. The theme name is just the community standard.
Themes really should use their theme name for the textdomain. Run your theme name through sanitize_title_with_dashes() to get the correct one.
Some translation systems may even require this. For example, TF may one day want to create a translation system on their site (like the one that exists at WordPress.org). The only way they could really do that, at least with a lot less hassle, is if theme authors were using the correct textdomains.
4 Likes
Justin - are you saying the framework code should also use theme name for textdomain? If so, it seems to defeat the purpose of the framework since this would require code changes in many framework functions with every theme.
There are two ways to work around this “issue”.
1) The framework itself can have its own separate textdomain with its own translation files that are loaded alongside the theme’s translation files. For that, you’d need a load_textdomain() call for the framework textdomain.
This method can actually be problematic when generating POT files for just the theme though because the framework strings will be added to the theme’s POT. I’m sure there’s ways around that using some systems for generating POTs. That’s something you’d want to look into if going this route.
2) The framework itself can have its own textdomain, but the strings get merged into the theme’s strings. This is the method I personally use because it allows a single translation for the entire theme + framework rather than separate translations.
To do this, you’d need a call to load_textdomain() for the framework. It’s basically a “dummy” call though. You’ll then hook into override_load_textdomain and overwrite global $i18n. You merge $i18n[ 'themename' ] with $i18n[ 'frameworkname' ].
4 Likes
Another way you could approach that problem is placing the framework to a plugin.
1 Like
I’ve done this. Only thing is is that it’s gets a bit messy need to check the plugin is loaded and function exists before using them. Perticulary in template files
Are we allowed to shorten the theme or framework name for use as a prefix? If for example my theme is called “Turbo Mega Constructions” can I use “tmc_” as prefix?
I ask because taxonomy has a 32 char limit in database and I would also imagine that performance would be worse with such a long prefix name (especially with regex for shortcodes).
- The framework itself can have its own textdomain, but the strings get merged into the theme’s strings. This is the method I personally use because it allows a single translation for the entire theme + framework rather than separate translations.
To do this, you’d need a call to load_textdomain() for the framework. It’s basically a “dummy” call though. You’ll then hook into override_load_textdomain and overwrite global $i18n. You merge $i18n[ ‘themename’ ] with $i18n[ ‘frameworkname’ ].
Isn’t that going to result in theme-check error “multiple text-domains found” ? Reviewers on TF reject because of it.
Yes, any method with more than one textdomain will give that info notice. If reviewers are rejecting themes because of a notice and not actually looking into the code itself, that’s probably something that needs to change. I’m not up to speed on how TF handles their reviews, so I can’t really say much about it. I’m merely speaking from the viewpoint of what works in code and would happily help with any explanations if any reviewer asks.
Edit: Sorry, I meant to reply via my regular account. I’m “greenshady” from above though.
2 Likes
We fixed all comment, resubmit our theme and receive only this message:
We’re now taking extra security measures and this needs to be corrected before we can continue.
Does anyone have this. Any feedback would be greatly appreciated.
Thank you.
What is this referring to?