I believe the reviewer was pasting in the script under the header of “No Filter Evasion” in many or all of my Theme Options settings that accepted data entry.
So for example, if in Theme Options, I have a setting where you can set the company phone number. In your theme where it is to echo the phone number, you have to escape it like this:
<?php echo esc_html(get_option(‘phone’))?>
Now, if you enter that script into the phone number field in Theme Options, and in the site you try and display that number, instead of that ugly XSS error, you will just see the code for the script instead. That’s what you want.
So I think you need to paste that script into all text fields in Theme Options, and then go around your site and make sure that popup with the error never shows up. That’s what I did, and the reviewer never brought it up after that.
Hope this helps!
I combed through all my theme files and escaped everything I could find. But still the reviewer calls me out on this. I just don’t know what to do now.
Does anyone know of a plugin that can help me debug these issues? The theme reviewer certainly must be using some kind of plugin that shows the problems.
This has been a requirement and best practice for some time now. Using the TGM Plugin Activation library makes it cake for users to install and activate the required plugins. http://tgmpluginactivation.com/
Use it in all my themes never had a buyer have an issue with it, pretty sure its the standard for all authors.
Ok, I see now why Custom Post Types and Taxonomies should be plugins… http://justintadlock.com/archives/2013/09/14/why-custom-post-types-belong-in-plugins (spoiler: data portability)
So if they are plugins, they need to be packaged along with the theme and the theme buyers must now install them separately? This seems like a lot more tech support and headaches.
They need to be plugins now? I think some of the requirements are just getting out of hand. Why would custom post types and taxonomies need to be plugins?
I have a theme customer saying that images don’t display when they switch to an SSL site: (https://). A google search found a thread where this seems to be an issue: https://github.com/syamilmj/Aqua-Resizer/issues/21 Is there any fix for this?
Is there a problem using this script with WPMU? One customer says images show up on a regular WP installation, but not when set up with WPMU. Is this a known problem or limitation?
I hit Plutonium this morning.