Scripting Guard breaks on codestyling-localization scripts

If have an alternative wp-content location, so my site_url is https://localhost/development/ and my content url is https://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];
    }
  }
}

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.

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.

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: https://xyz.tld

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?

@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 https:// call to https://

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', 'https://localhost/wp-content');

So my site urls are https://localhost/development/ and https://localhost/wordpress/ both share the content url of https://localhost/wp-content/

@macbrink: can be done with symlinks instead of doing extra stuff within the config. Also at Windows using https://en.wikipedia.org/wiki/NTFS_symbolic_link

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.

define( ‘WP_CONTENT_DIR’, dirname(dirname(__FILE__)) . ‘/wp-content’);
define( ‘WP_CONTENT_URL’, ‘https://localhost/wp-content’);

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.

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.

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.

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.

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.