Mike Wilson

If you aren’t willing to pay for the upgrade (it is a lot for a compatibility fix) and want to update WP to 4.3+. a better alternative to messing with the core of your WP install is to crack open the plugin, debug it, and fix it yourself. If you don’t want to or can’t pay for support and upgrades, which you agree to when you purchase, then update and support the plugin yourself.

Hi,

Just wanted to confirm that as of today’s build of Minefield 4.0b8pre, this bug seems to be fixed.

Yea, I kinda figured it was but with everything I’m using being in beat, LOL, plus the fact that I’m adding custom meta boxes to the edit screens on this particular site, I thought it was prudent to check here too. =)

I’ve submitted a bug into Mozilla’s bugzilla for this, so hopefully they will take care of it soon…

Thanks for helping me eliminate WordPress from the bug. =)

Hi Demetris,

Do you have multiple visual editors (separate instances of the WYSIWYG) on the WordPress screen you tested?

Mike

Hi,

My apologies – it was late or early depending on how you look at it, lol! I am also running 4.0b8pre and just auto-updated this morning, so we should be on the same page.

I’ve gone through it a little more thoroughly and, like Bug 605481, it seems to only trigger when there are multiple instances of the visual editor in place. It also appears that it does not seem affect the last instance of the editor to “load”(?).

It’s most likely a Firefox issue, but because I’m using a WordPress beta (and also not just my on test case for TinyMCE), I wanted to see if anyone else could reproduce it.

I’m not sure how to go about “reopening” a resolved bug on Bugzilla…

Thanks,
Mike

Thanks! I’ll keep an eye out for an update and report back anything new.

Hi,

I can’t switch themes, but it’s not likely something in my theme …or at least not anything “odd”. My functions.php for this theme is pretty sparse, containing only one function: “remove_dashboard_widgets()”, which pulls specified metaboxes off the admin dashboard and doesn’t have any affect on the user-facing portion of the site.

As for the code that was generating the links that wouldn’t respond to your plugin… I think I’ve got it narrowed down to any link containing “<?php bloginfo(‘url’); ?>”. Hard coded links that use the static url (e.g. https://www.mysite.com/) work as expected.

I just updated this site to 3.0 last week, so to test this issue further, I implemented the new “menu” system, and Bob’s your uncle… your plugin started working for the main navigation as well.

So as far as I can tell, any hard coded link that contains “<?php bloginfo(‘url’); ?>”, still points to https.

Hey Mvied,

Nope… not working for me.

I reverted the change to link-template.php I posted above and uploaded, verified the automatic https links had indeed returned, updated your plugin, selected “Disable Automatic HTTPS”, and saved. When I view any https page on my site, all the post and page links are still https.

If I make the change to link-template.php again, all the links revert to standard HTTP.

WordPress 3.0.1.
WordPress HTTPS 1.0.1

Wow after an hour of searching I think I finally found something useful…

WordPress Version: 3.0.1
Core File: wp-includes/link-template.php
Lines: 1840-1872 (for me at least)

/**
 * Retrieve the home url for a given site.
 *
 * Returns the 'home' option with the appropriate protocol,  'https' if
 * is_ssl() and 'http' otherwise. If $scheme is 'http' or 'https', is_ssl() is
 * overridden.
 *
 * @package WordPress
 * @since 3.0.0
 *
 * @param  int $blog_id   (optional) Blog ID. Defaults to current blog.
 * @param  string $path   (optional) Path relative to the home url.
 * @param  string $scheme (optional) Scheme to give the home url context. Currently 'http','https'
 * @return string Home url link with optional path appended.
*/
function get_home_url( $blog_id = null, $path = '', $scheme = null ) {
	$orig_scheme = $scheme;

	if ( !in_array( $scheme, array( 'http', 'https' ) ) )
		$scheme = is_ssl() && !is_admin() ? 'https' : 'http';

	if ( empty( $blog_id ) || !is_multisite() )
		$home = get_option( 'home' );
	else
		$home = get_blog_option( $blog_id, 'home' );

	$url = str_replace( 'https://', "$scheme://", $home );

	if ( !empty( $path ) && is_string( $path ) && strpos( $path, '..' ) === false )
		$url .= '/' . ltrim( $path, '/' );

	return apply_filters( 'home_url', $url, $path, $orig_scheme, $blog_id );
}

I don’t know what the hell I’m doing really… but I just changed the following:

$scheme = is_ssl() && !is_admin() ? 'https' : 'http';

to

$scheme = is_ssl() && !is_admin() ? 'http' : 'http';

And it seemed to revert back to the standard behavior… I’m more than sure there is a better way to work around this… maybe using some sort of filter in functions.php… I’m just not at all sure where to start with something like that.

Works great now! Thanks! =)

Howdy,

I should have done this before, but since I was just posting a “me too” I wasn’t thorough… Apologies. I narrowed it down to a conflict with the WP-PageNavi Version 2.72 plugin. https://www.ads-software.com/extend/plugins/wp-pagenavi/

I’m not sure exactly what’s going on, but activating WP-PageNavi causes the problem – at least for me.

Anointed can you confirm this?

I get the incorrect WP header and footer errors, but otherwise the plugin seems to be working fine for me. I’m using it on a client’s site tho… so I had to deactivate it until we get a fix.

SexyBookmarks 3.2.4.1 & WordPress 3.0.1

In case it helps… here’s how I register my taxonomies:

function register_my_taxonomies() {

// My Taxonomy
register_taxonomy(
	'my-taxonomy',
	array( 'post',
    	       'page' ),
	array( 'hierarchical' => true,
	       'label' => 'My Taxonomy',
	       'query_var' =>  true,
	       'rewrite' => true
	      )
	);
}

I deleted and re-added the widget with no change – still get “array” rather than any taxonomies…

I then deactivated the plugin, deleted the plugin, reinstalled, and re-added the widget and still have the same issue.

I can confirm this behavior on QMT 1.3 & WP 3.0.1.