Title: Scripting Guard breaks on codestyling-localization scripts
Last modified: August 20, 2016

---

# Scripting Guard breaks on codestyling-localization scripts

 *  Resolved [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/)
 * The scripting Guard finds codestyling-localization files to be dubious?
 * > Malfunction at dubious external scripts detected !
   >  Reason: unknown external
   > script has been enqueued or hardly attached. | Polluter: unknown (probably 
   > by Theme or Plugin) Below listed external scripts have been traced, verified
   > and automatically stripped because of injection: [hook:admin_head#0] – [http://localhost/wp-content/plugins/codestyling-localization/js/prototype.js](http://localhost/wp-content/plugins/codestyling-localization/js/prototype.js)[
   > hook:admin_head#4] – [http://localhost/wp-content/plugins/codestyling-localization/js/wp-scriptaculous.js](http://localhost/wp-content/plugins/codestyling-localization/js/wp-scriptaculous.js)[
   > hook:admin_head#5] – [http://localhost/wp-content/plugins/codestyling-localization/js/effects.js](http://localhost/wp-content/plugins/codestyling-localization/js/effects.js)
 * How to fix this?
 * [http://wordpress.org/extend/plugins/codestyling-localization/](http://wordpress.org/extend/plugins/codestyling-localization/)

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

 *  Thread Starter [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441134)
 * If have an alternative wp-content location, so my site_url is [http://localhost/development/](http://localhost/development/)
   and my content url is [http://localhost/wp-content/](http://localhost/wp-content/).
   
   I found some issues in the logic to determine if it is an external script: in
   codestyling-localization.php on line 2554
 *     ```
       if( stripos($url[1], content_url()) !== false && csp_plugin_denied_by_guard($url[1]) )
       ```
   
 * is false because the script is on content_url, but csp_plugin_denied_by_guard()
   returns false.
    the next test on line 2564 tests on site_url() which will return
   false
 *     ```
       elseif (stripos($url[1], get_site_url()) === false && !in_array($url[1], $csp_external_scripts['cdn']['scripts']))
       ```
   
 * I would propose to split the if statement on line 2554 in two parts, first check
   for content_url is true and the check for denied scripts, something like this:
 *     ```
       if( stripos($url[1], content_url()) !== false ) {
         //internal scripts
         if ( csp_plugin_denied_by_guard($url[1]) ) {
           $dirty_scripts[] = $url[1];
           $dirty_index[] = $i;
           if (stripos($url[1], plugins_url()) !== false || stripos($url[1], content_url().'/mu-plugins') !== false) {
             $dirty_plugins[] = $url[1];
           }else{
             $dirty_theme[] = $url[1];
           }
         }
       }
       ```
   
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441159)
 * get_site_url() delivers the option save during install at the wp_options table
   as siteurl. This may not match with your current blog/wordpress url and thatswhy
   it will be handled as not same origin.
    I have this case currently reported by
   a live blog too, where the user first installs the blog not using www. but changed
   it afterwards to have www. within the urls by changing the urls at settings page.
   But this doesn’t update the siteurl option in database and will lead to that “
   not same origin” detection.
 * I will check those cases more specific with next update but afraid, that this
   is a wp core bug too.
 *  Thread Starter [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441191)
 * IMHO this is not a core bug. My site url and content url have to be different.
   
   The problem is in the combined if statement. The codestyling-localization scripts
   are in content_url, but the test in `csp_plugin_denied_by_guard()` returns _false_,
   and thus the whole if statement is false.
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441210)
 * Could you explain, what did you setup (example) to understand the difference 
   between not matching with get_site_url() the same url start as with content_url()?
   
   Because the test runs against “must be starting with”, so I could only understand
   it, if your content dir is from a different domain (or subdomain). Otherwise 
   both url’s should start the same way: `http://xyz.tld`
 *  [Unsal Korkmaz](https://wordpress.org/support/users/unsalkorkmaz/)
 * (@unsalkorkmaz)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441215)
 * i think i have a similar problem..
    have multisite and i am defining those:
 *     ```
       define( 'WP_CONTENT_URL', '//' . DOMAIN_CURRENT_SITE . '/wp-content');
       define( 'WPMU_PLUGIN_URL', '//' . DOMAIN_CURRENT_SITE . '/wp-content/plugins');
       ```
   
 * plugin is not working just because of ‘//’. When i remove those, its working:
 *     ```
       define( 'WP_CONTENT_URL',  DOMAIN_CURRENT_SITE . '/wp-content');
       define( 'WPMU_PLUGIN_URL',  DOMAIN_CURRENT_SITE . '/wp-content/plugins');
       ```
   
 * i am trying to prepare multisite for ssl usage so dont want to define http or
   https. Can you give me a solution for this?
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441221)
 * **[@unsalkorkmaz](https://wordpress.org/support/users/unsalkorkmaz/)**: WordPress
   3.5.x is working out of the box with either SSL or none SSL requests out of the
   box. I have a local testsystem with multisite and several subdomains and a self
   certified wildcard certificate and can freely choose to visit admin and frontpage
   with SSL or non SSL as I need it at any time.
 * I did only setup 2 vhosts one configured to post 80 (non SSL) and one to port
   443 (SSL) and both using then same document root.
    This should be the case at
   providers too or can be at least configured to the same document root.
 * Thats it. Now the WordPress installation is callable at any time with both options.
   if you want to avoid non SSL entirely, just place a .htaccess rule to redirect
   any http:// call to https://
 *  Thread Starter [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441224)
 * In my development environment, localhost, I develop for WordPress trunk and for
   current stable version. Both WordPress installs share a wp-content directory.
   
   In wp-config I have:
 *     ```
       define( 'WP_CONTENT_DIR', dirname(dirname(__FILE__)) . '/wp-content');
       define( 'WP_CONTENT_URL', 'http://localhost/wp-content');
       ```
   
 * So my site urls are `http://localhost/development/` and `http://localhost/wordpress/`
   both share the content url of `http://localhost/wp-content/`
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441225)
 * **[@macbrink](https://wordpress.org/support/users/macbrink/)**: can be done with
   symlinks instead of doing extra stuff within the config. Also at Windows using
   [http://en.wikipedia.org/wiki/NTFS_symbolic_link](http://en.wikipedia.org/wiki/NTFS_symbolic_link)
 *  Thread Starter [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441228)
 * Yes, maybe, but because the site url does not have to be a part of content url,
   I have this setup. My plugins should also work when someone has set it up like
   this. (and I think so should yours)
    BTW I don’t want symlinks because I need
   the directories separately for other purposes.
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441233)
 * > define( ‘WP_CONTENT_DIR’, dirname(dirname(__FILE__)) . ‘/wp-content’);
   >  define(‘
   > WP_CONTENT_URL’, ‘[http://localhost/wp-content&#8217](http://localhost/wp-content&#8217););
 * Defining the url without any need to be different (dir sharing is suitable enough)
   you just higher the barrier to plugins to fail and you would create mixture of
   SSL and none SSL content even in admin area!
    Sure, I can handle such artificial
   cases. But in my opinion this is far away from reality.
 * BTW: symlinking only the shared content folder into the separated installs.
 *  Thread Starter [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441235)
 * Okay, I guess you don’t want to update your plugin. I have made some changes 
   to your plugin and it works for me now.
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441237)
 * Don’t guess, what I will do or not.
    It more than unprofessional, what do you
   think you have to tell the world what is right or wrong. You are creating non
   real live scenarios and trying to explain that it’s common use in the wild. It
   isn’t! Futhermore I support my plugins as best as possible but not without analysing
   it in detail.
 *  Thread Starter [Marcel Brinkkemper](https://wordpress.org/support/users/macbrink/)
 * (@macbrink)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441239)
 * Hey please don’t go that way. I haven’t told anyone what is wrong or right. I
   have only shared my thoughts with you. No hard feelings.
 * I do love your plugin, it is one of the best localization plugins I have ever
   used. Next time, I’ll think twice about making some suggestions on your plugin.
 *  Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/)
 * (@codestyling)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441240)
 * A similar case occured in quite different thread but was addressed by renaming
   the blog and wordpress url at settings page weeks after install with the www.
   subdomain prefix. From that point on any call to get_site_url() doesn’t return
   the domain with the www. subdomain extension but the 1st install saved pure domain
   at the option table.
 * That’s why I do a full spectrum analysis first with all occured behavior to find
   the best matching overall solution.
    And yes, it looks like a bug in single installs,
   if I rename both setting page values and get afterwards at get_site_url() an 
   unexpected/unlogical value.
 * Don’t get me wrong, I will deal with all incomming reports sooner or later but
   software can’t be free of bugs because it runs on top of hard- and software also
   not free of bugs. So nobody is able to deal upfront with each and any potential
   occuring issue. I know, what I’m talking about, normally at my profession I have
   to deal, write and maintain C++ software with more than 20 million of code lines
   running at high critical companies.

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

The topic ‘Scripting Guard breaks on codestyling-localization scripts’ is closed
to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/codestyling-localization_e6e1e3.svg)
 * [Codestyling Localization](https://wordpress.org/plugins/codestyling-localization/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/codestyling-localization/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/codestyling-localization/)
 * [Active Topics](https://wordpress.org/support/plugin/codestyling-localization/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/codestyling-localization/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/codestyling-localization/reviews/)

## Tags

 * [Scripting Guard](https://wordpress.org/support/topic-tag/scripting-guard/)

 * 14 replies
 * 3 participants
 * Last reply from: [codestyling](https://wordpress.org/support/users/codestyling/)
 * Last activity: [13 years, 3 months ago](https://wordpress.org/support/topic/scripting-guard-breaks-on-codestyling-localization-scripts/#post-3441240)
 * Status: resolved