Scripting Guard - a WordPress Plugin protects itself
codestyling | 08. June 2012 | 08:38
I receive constantly support requests about my plugin Codestyling Localization and have to figure out, what is the real problem behind the reported incident. This is annoying and stops me going on with development as fast as I could do. In 99.9% of all cases this is forced by a Theme or Plugin, which injects its own scripts into each and every backend page. To stop this high ammount of support activity I decided to protect my plugin against such incidents. Starting version 1.99.21 it introduces a “Scripting Guard”.
Malfunction of Themes and Plugins
There are a lot of possible problems forced by Themes or Plugins that may break your WordPress installation. In most cases the reason for such defects are Javascripts, which will be injected into all backend pages either accidentally, intentionally or simply be ignorance of the author behind.
Following types of incidents can occur:
- The Theme integrates it’s scripts not only at Frontend but also at entire Backend.
- A Plugin integrates it’s scripts to entire Backend Pages and not only to it’s own Pages.
- Badly integrated scripts raising javascript runtime exceptions and stop execution of real necessary scripts.
All of this incident types will be catched, traced and handled by my plugin now. Doing so, I can ensure, that my plugin will work as expected without any side effects to any other Plugin or Theme.
Scripting Guard
If at least one of the above listed types of incidents has been happend, my plugin starts protecting itself, traces all incidents and shows after page creation a warning message about. If you expand the details, you can clearly find any blocked incident, who is reponsible for, why this have been blocked and which author should rework it’s Plugin or Theme as fast as possible.
The screenshot beside shows a live example how this could look like in your blog.
If you want to see this live at your system but you haven’t a malformed installation, you can currently install WooCommerce or the Theme NomNom. Both are forcing at the moment such incidents and will be handled by my plugin successful.
Conclusion
As long as the Authors informed by Mail, that there is somethings wrong at their Plugins or Themes, don’t react on my suggestions and hints, I have to protect the plugin against those incidents. For unexperienced WordPress user it is not easy to find out, why something is not working as expected. Thats why I have chosen this kind of protection handling to show such problems clearly and also provide solid arguments for blog owner to discuss the problems with the affected Authors.
I’m sure, that not all of the affected Author will be happy about that and may be not prepared to handle the upcomming support requests, but I don’t see any other ways to protect the proper function of my plugin and also force other Authors to write clean code and play nicely within WordPress.
Version 1.99.21 is the first one, that contains this “Scripting Guard”. The protection will be enlarged over time with more incidents, currently a CDN script redirect warning is about to be published additionally with the next updates.
I’m interested in your thoughts about and really appreciate your feedback.






Paul
18.06.2012 | 22:49I thik that it is great idea - just today I removed two plugins reported by Scripting Guard. I will search for safe replacement. I had few strange errors on my blog, it is possible that misbehaving plugin was the cause.
reply »