julianm

It’s the changes on line 175 in wp-includes/canonical.php that are causing this issue.

-		} elseif ( is_page() && !is_feed() && isset($wp_query->queried_object) && 'page' == get_option('show_on_front') && $wp_query->queried_object->ID == get_option('page_on_front')  && ! $redirect_url ) {
+		} elseif ( is_page() && !is_feed() && 'page' == get_option('show_on_front') && get_queried_object_id() == get_option('page_on_front')  && ! $redirect_url ) {

https://github.com/WordPress/WordPress/commit/84a3b4407f9e03311aa591004f3bec0639f3ba3f

I’m having the same problem after upgrading to 4.5. I’m redirecting the to a subdomain for logged in admins, to get around some caching issues to do with CloudFlare CDN, ModPagespeed, etc. Since upgrading, this is no longer working on my static front page.

https://www.example.com redirects to admin.example.com when a user is logged in. This works for all pages except the homepage, where a redirect loop between https://www.example.com and admin.example.com causes infinite redirects.

Awesome, thank you! I’ve subscribed to the issue on GitHub also.

That didn’t seem to work. Here’s what happens using those two functions…

add_filter( 'jetpack_mobile_stylesheet', function( $stylesheet, $theme ) {
	$ss = get_theme_root() . 'mobile';
	return $ss;
} );

Adds the following:

<link rel='stylesheet' id='style-css'  href='https://www.[DOMAIN].com/cms/wp-content/plugins/jetpack/modules/minileven/theme//home/[USER]/public_html/cms/wp-content/plugins/jetpack/modules/minileven/thememobile/style.css?ver=4.1.4' type='text/css' media='all' />

add_filter( 'jetpack_mobile_stylesheet', function( $stylesheet, $theme ) {
	$ss = get_theme_root_uri() . '/mobile';
	return $ss;
} );

Adds the following:

<link rel='stylesheet' id='style-css'  href='https://www.[DOMAIN].com/cms/wp-content/plugins/jetpack/modules/minileven/theme/http%3A//www.[DOMAIN].com/cms/wp-content/plugins/jetpack/modules/minileven/theme/mobile/style.css?ver=4.1.4' type='text/css' media='all' />

Hi Jeremy. If I use just “mobile” as the return string, Jetpack tries to load it from here:

/wp-content/plugins/jetpack/modules/minileven/theme/mobile/style.css?ver=4.2.1

add_filter( 'jetpack_mobile_stylesheet', 'mobile_theme_callback' );

add_filter( 'jetpack_mobile_template', 'mobile_theme_callback' );

function mobile_theme_callback(  ) {
	return 'mobile';
}

The only problem with this is that updating the plugin removes the theme directory.

This can be tested with the jetpack_mobile_stylesheet filter. If testing with jetpack_mobile_template filter, it produces a fatal error.

Hi Jeremy,

I’ve tried it, but it didn’t seem to work. It seems to default to a path relative to the plugin’s mobile theme folder. What would the string look like if I wanted to use the following path, for example?

wp-content/themes/mobile/custom/styles.css

Instead of this one:

wp-content/plugins/jetpack/modules/minileven/theme/cutom/mobile/style.css

There is an error on line 155 of version 1.0, which I found to be causing the problem.

The code:

if ( !empty( $lastmod ) ) {
     date( 'c', strtotime( $lastmod ) );
}

Should be:

if ( !empty( $lastmod ) ) {
     $lastmod = date( 'c', strtotime( $lastmod ) );
}

No problem. Glad I could help. Unfortunately, a plugin update will overwrite the fix. The best solution would be for the plugin authors to fix it on the repository. I also noticed that the Email button opens a blank popup with this fix.

@merkucio You need to add it in the rrssb.min.js file.

Do a search for the following snippet…

t(".rrssb-buttons a.popup").on("click",function(e){var n=t(this);l(n.attr("href"),n.find(".text").html(),580,470);e.preventDefault()})

…and replace it with this…

t(document).ready(function(){t(".rrssb-buttons a.popup").on("click",function(e){var n=t(this);l(n.attr("href"),n.find(".text").html(),580,470);e.preventDefault()})})

Adding The following to the JavaScript fixed the popup problem for me:

t(document).ready(function(){t(".rrssb-buttons a.popup").on("click",function(e){var n=t(this);l(n.attr("href"),n.find(".text").html(),580,470);e.preventDefault()})});

Same issue here.

Hi! Yes, that’s what the JavaScript inserts into the page, and it effectively hides the <p> element with class “nemonn” (the pharma-related link spam) from regular users. It is visible to search engines, though, and this malware will have a lot of negative impacts on an infected website.

The JavaScript snippet is well known as malware, especially the function name “xViewState”. There’s some more info here:

https://blog.sucuri.net/2012/12/website-malware-sharp-increase-in-spam-attacks-wordpress-joomla.html

Here is another compromised WordPress site that Quttera flagged as clean:
https://goo.gl/hTbdj

This is the source code:
https://pastebin.com/XvaFwxKs

Unfortunately, I’ve already cleaned the site, and the exploits were deleted, but I will email you the site address. Since I have absolutely no association with the website, only that the client asked me to remove the malware, I’d prefer not to post the address publicly.

I’m dealing with a lot of infected sites as of recently, though, and since you seem genuinely interested in feedback, I’m willing to give this plugin another go. Having said that, most of the infected sites I’m seeing are Joomla sites; not a lot of WordPress sites.

Hello! There was a malicious JavaScript snippet in the theme’s header.php template. The file didn’t didn’t show specifically in the scan results, as it seems the plugin doesn’t do any local scanning, but the code would have been included by all public WordPress pages. I think the plugin has potential, but as, it is kind of limited in what it’s able to detect – for example, .htaccess files are excluded, and also conditional redirects, if there is no local scanning.

Apologies if my review seems negative. These were just my thoughts. If there’s anything I can do to help, please give me a shout.