Title: WP_DEBUG warnings
Last modified: August 30, 2016

---

# WP_DEBUG warnings

 *  Resolved [wpweaver](https://wordpress.org/support/users/wpweaver/)
 * (@wpweaver)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/)
 * Getting these with WP_DEBUG true
 * Version: 20150818.1
 * Notice: Undefined offset: 0 in /…/wp-content/plugins/theme-check/checks/i18n.
   php on line 48
 * Notice: Undefined offset: 2 in /…/wp-content/plugins/theme-check/checks/textdomain.
   php on line 82
 * [https://wordpress.org/plugins/theme-check/](https://wordpress.org/plugins/theme-check/)

Viewing 11 replies - 1 through 11 (of 11 total)

 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500012)
 * With what theme?
 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500121)
 * After looking at another theme causing this problem, I found that if you have
   function calls to one the various translation functions, and include too many
   arguments, then this problem can occur. I’ll look into fixing the warning, or
   at least trying to notify the user that one of their function calls is messed
   up.
 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500126)
 * These issues are now fixed in the latest version on GitHub:
 * [https://github.com/Otto42/theme-check/commit/b79f797b3922eebbda22fe714c6bc13f9f2c1265](https://github.com/Otto42/theme-check/commit/b79f797b3922eebbda22fe714c6bc13f9f2c1265)
   
   [https://github.com/Otto42/theme-check/commit/baa64a10972386f62091ba73cc79140acb151547](https://github.com/Otto42/theme-check/commit/baa64a10972386f62091ba73cc79140acb151547)
 *  Thread Starter [wpweaver](https://wordpress.org/support/users/wpweaver/)
 * (@wpweaver)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500178)
 * Thanks, Otto.
 * With a thousand translation calls (Weaver Xtreme), it does seem likely that there
   could be an extra argument.
 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500185)
 * Thanks for letting me know the name.
 * This is a problem:
 *     ```
       $err_msg .= __('Warning - your host may be configured to limit how many input var options you are allowed to pass via PHP.' .
       		' Unfortunately, this means your settings may not be saved correctly. See the "Weaver II Doesn\'t Save Settings" FAQ on weavertheme.com.<br />', 'weaver-xtreme' /*adm*/);
       ```
   
 * Because you used string concatenation here to break this string into two lines,
   it won’t be parsed properly by i18n scanning code. Meaning that this line cannot
   be properly translated. Gotta use plain single quoted strings only for translation
   functions. It’s not a problem for the PHP to put things together, but scanning
   tools to build string lists don’t run your code, they just scan it.
 * This bit of code simply contains too many arguments:
 *     ```
       __('Container Area', 'weaver-xtreme' /*adm*/, 'weaver-xtreme' /*adm*/)
       ```
   
 * Additionally, you have a large number of `_n_noop` calls missing a text domain(
   they’re all in tgmpa), and that code is also using the wrong text domain (‘tgmpa’
   instead of ‘weaver-xtreme’).
 * It found four different text domains in fact: weaver-xtreme, weaverx_axtreme,
   weaverx-xtreme, tgmpa. Might be worth standardizing all of them.
 * And finally, the strings ‘Post Comment’, ‘Leave a Reply’, and ‘Cancel Reply’ 
   are missing a text domain in comments.php.
 * Hope that helps.
 *  Thread Starter [wpweaver](https://wordpress.org/support/users/wpweaver/)
 * (@wpweaver)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500189)
 * Thanks for your response.
 * I knew about the missing text domains in the tgmpa code on the _n_noop calls –
   this is being discussed on the tgmpa site, and is a result of them being missing
   in earlier versions of their sample code and the recent improvement in Theme 
   Check with translation strings and calls.
 * And it would be good to get a clarification on the ‘tgmpa’ text domain issue.
   That string is in the tgmpa library code directly, and I think they switched 
   to that over a variable used in earlier versions to get around Theme Check, and
   that you would find that ‘tgmpa’ remains in a lot of themes that use tgmpa (and
   a lot do). So, what would be your recommended practice on this? Replace the ‘
   tgmpa’ text domain with the theme/plugin text domain in the library, leave it
   as ‘tgmpa’ and register it as an additional text domain, or something else. I
   think a lot of people would be happy to get this issue settled once and for all.
 * I know you aren’t fond of tgmpa, and in many ways I agree suggested plugins could
   be presented much more compactly. But it does offer some very nice features, 
   and handles all the messages and plugin loading code without much thought by 
   theme developers.
 * For me, the hardest thing with tgmpa over time has, in fact, been dealing with
   the text domain name for it, and how Theme Check handles that.
 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500193)
 * > So, what would be your recommended practice on this? Replace the ‘tgmpa’ text
   > domain with the theme/plugin text domain in the library
 * Yes, this. Simple search/replace should do the job.
 * Any strings that you don’t have using the text-domain for your theme will not
   get translated properly in the language pack system. It only works on the text-
   domain that matches your slug.
 * As for duplication of the same string across themes, this is a non-issue because
   having all the strings for all the themes in the same place (translate.wordpress.
   org) means it only needs to be translated once. Then all other themes using the
   same strings get the benefits.
 * A theme or a plugin should have one, and only one, text domain associated with
   it.
 *  Thread Starter [wpweaver](https://wordpress.org/support/users/wpweaver/)
 * (@wpweaver)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500195)
 * Thanks, Otto.
 * Unfortunately, a simple search/replace for ‘tgmpa’ to ‘theme-slug’ will not work
   as the library uses ‘tgmpa’ for other purposes as well.
 * I think I’ll pass along your recommendation to TGMPA about the translation issue,
   perhaps they can provide a workaround. Perhaps a defined CONSTANT that could 
   be unique, and more easily replaced. But no matter what, needing to manually 
   update this string for each new version will be a hassle.
 * What do other theme libraries do about translation strings? Certainly this must
   come up with other theme support frameworks or libraries?
 * And, the fact that you were able to detect different translation variants would
   be a great diagnostic addition to Theme Check.
 * All the weaver variants you found were really leftovers from the required addition
   of admin side translations a while back – didn’t get them all done right.
 * And you might even add a special message for ‘tgmpa’ if that is what you guys
   really consider important.
 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500197)
 * > And, the fact that you were able to detect different translation variants would
   > be a great diagnostic addition to Theme Check.
 * That’s already in there. 🙂
 * The exact message theme check currently spits out for your theme is this:
 *     ```
       INFO: More than one text-domain is being used in this theme. This means the theme will not be compatible with WordPress.org language packs.
       The domains found are weaver-xtreme, weaverx_axtreme, weaverx-xtreme, tgmpa, Unfortunately, this means your settings may not be saved correctly. See the Weaver II Doesn\t Save Settings FAQ on weavertheme.com.
       ```
   
 * That last one of “Unfortunately…” comes from the case above where you’re using
   string concatenation. It sees the second string in the __() function as being
   the text-domain.
 *  Thread Starter [wpweaver](https://wordpress.org/support/users/wpweaver/)
 * (@wpweaver)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500202)
 * Very cool.
 * I’m working on a last pre-Customizer requirement of the theme right now.
 * I think this new feature will be a big help.
 * I do think, however, that this issue does bring up an inconsistency in the theme
   requirements: [https://make.wordpress.org/themes/handbook/review/required/](https://make.wordpress.org/themes/handbook/review/required/)
 * One requirement in the Language section is:
 * > Use a single unique theme slug – as the theme slug appears in style.css. If
   > it uses a framework then no more than 2 unique slugs.
 * This is about the language slug, and says a 2nd slug for a framework is allowed–
   but the new INFO message from Theme Check indicates that a 2nd slug can break
   compatibility with the language pack. This seems like an inconsistency. I think
   this brings up something that needs attention from the theme review team.
 *  Plugin Author [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * (@otto42)
 * WordPress.org Admin
 * [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500207)
 * Compatibility with language packs is not currently required by the review guidelines.
   It’s just highly recommended.
 * Language pack support for themes was added relatively recently. No reason to 
   go full bore all at first. Give people time to learn about it and figure it out
   before shoving it down their throats, sort of thing.
 * This is why those checks return INFO responses. I do have it return WARNING messages
   for a couple text-domain checks, but those don’t currently fail the theme. They’re
   just there in red to get your attention as something definitely broken somewhere.

Viewing 11 replies - 1 through 11 (of 11 total)

The topic ‘WP_DEBUG warnings’ is closed to new replies.

 * ![](https://ps.w.org/theme-check/assets/icon-128x128.png?rev=972579)
 * [Theme Check](https://wordpress.org/plugins/theme-check/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/theme-check/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/theme-check/)
 * [Active Topics](https://wordpress.org/support/plugin/theme-check/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/theme-check/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/theme-check/reviews/)

 * 11 replies
 * 2 participants
 * Last reply from: [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/)
 * Last activity: [10 years, 8 months ago](https://wordpress.org/support/topic/wp_debug-warnings-3/#post-6500207)
 * Status: resolved