Matt

Thanks for figuring that out. Worked for me too.

Does that do the same thing as deleting the readygraph-extension.php file? Cause looking through the code I saw that’s all I needed to do so that’s what I did.

As far as reproducing the errors, I don’t know. I did not have readygraph enabled any further than how it comes with the plugin by default. The options I have enabled are:

Print
Email
Twitter
Facebook share (new) [counter not checked]
Facebook like [app id specified]

The errors show up in IE’s developer console and also similar errors using firefox along with firebug.

The “HTTPS security is compromised by” is referring to the face that when viewing a page using HTTPS the content is still being pulled via HTTP.

I did not, but I just replaced the gif.

having the same issue here.

edit: never mind, mine was a redirect issue on my end.

great

How bout this…

*ignore my first post and undo that change.

*Add a new column to your database: tiny_int (1 or 0) titled ‘found_in_shortcode’ or something.

containers.php–

synch function:

Line 274: $all_instances_found = array();

Line 282: if (!empty($found_instances)) { $all_instances_found = array_merge($all_instances_found, $found_instances); }

Line 291:

if ($field == 'post_content' || (empty($field) && $this->default_field == 'post_content')) {
	$shortcode_expanded = do_shortcode($value);
	//Parse the field with each parser
	foreach($parsers as $parser){
		$found_instances_with_shortcode = $parser->parse( $shortcode_expanded, $base_url, $default_link_text );

		//note sure if array_unique or something better could be used here
		foreach($found_instances_with_shortcode as $key => $shortcode_instance) {
			foreach($all_instances_found as $instance){
				if ($shortcode_instance->raw_url == $instance->raw_url && $shortcode_instance->link_text == $instance->link_text) {
					unset($found_instances_with_shortcode[$key]); break;
				}
			}
		}

		foreach($found_instances_with_shortcode as $shortcode_instance){
			$shortcode_instance->found_in_shortcode = 1;
			$shortcode_instance->set_container($this, $name);
			$shortcode_instance->save();
		}
	}
}

instances.php–

Line 27: var $found_in_shortcode = 0;
Lines 236 and 275: update queries to write ‘found_in_shortcode’ value

Then on the admin form, pull and check that value. If “found_in_shortcode” == 1 then display a text “Embdedded in shortcode” and disable the links that are used to fix it.

I think you should detect when a link is found within shortcode and then display those links differently on the broken link lists. Alert the user they were found in shortcode and can’t be fixed automatically. Ideally, at least direct the user to the post/page they were found in (right-most column that you already have).

The name of the plugin is “Broken Link Checker” and I don’t think you should sacrifice the ability to find broken links simply because you can’t do magic on all of them.

Thanks for the props, much appreciated. What happened to the url for the plugin? Saying it doesn’t exists now.

Turns out it was my fault. I recently renamed be database prefixes for security and forgot to update the options table on the subsite table. Once I ran UPDATE NEWPREFIX_2_options SET option_name = REPLACE( option_name , ‘OLDPREFIX_2_’, ‘NEWPREFIX_2_’ ) the issue went away.

That fixed it but I wanted to look into why it may be causing it on my end based on what you said. Turns out it was my fault. I recently renamed be database prefixes for security and forgot to update the options table on the subsite table. Once I ran UPDATE NEWPREFIX_2_options SET option_name = REPLACE( option_name , ‘OLDPREFIX_2_’, ‘NEWPREFIX_2_’ ) the issue went away.

Only one dealing with users is this one: https://www.ads-software.com/plugins/user-role-editor/

(logged in as super admin though)

I just did a re-optimize (forced) and it hung up on this file again. Don’t know what the deal is.

I am not able to replicate the problem now. I will post a new thread if it happens again.

Uhg, sorry to keep posting updates, but I just noticed my regex was wrong in the last update. Line 317, instead of:

$regex = addcslashes(“^(“.preg_quote($issue->path).”)(.*)”, ‘/’);

should be this instead:

$regex = “^(.*)(\\s\\(\\+.*)$”;

Updated file: https://www.dropbox.com/s/gkfdud7jye2zhiz/wp-media-cleaner.php?dl=0

After reviewing my changes again with a fresh head I had some minor improvements:

Updated file: https://www.dropbox.com/s/gkfdud7jye2zhiz/wp-media-cleaner.php?dl=0

File Compare: https://www.diffnow.com/?report=sgopn

Changes:

function wpmc_wp_ajax_wpmc_scan
188: Added braces. Again I don’t like not using them on multi-lines.

205: I moved the part about removing alternate image sizes into the “if ( wpmc_getoption( ‘scan_media’, ‘wpmc_basics’, true ) ) {” section since it is only relevant when scanning media. I suppose it could be wrapped with “if ( wpmc_getoption( ‘scan_files’, ‘wpmc_basics’, true ) ) {” as well, or have the whole thing moved down and then wrapped with both. But $files will be empty if not scanning files anyway so it’s negligible.

function wpmc_delete( $id ) {
313: I realized that since we are inserted into the database with “path/filename.ext (+ add files)” that the ” (+ X files)” needs to be stripped off in order to check for a media DB and to delete the files correctly. Also since we are stripslashing before inserting into the database now the stripslashes would be redundant here and could potentially mess up the filename, though I think there should never be backslashes in the filename at this stage anyway? So maybe leave it in, shrug.

NOTE: Because of these changes with the stripslashing of the filename, people should probably be informed to do a “reset” for scanning again.

function wpmc_check_db_has_meta
512: What I had initially done with “if (empty($attachment_id)) $attachment_id = -1;” was sloppy. I changed it around to be better.