brokkr

Hi Matt,

Apologies for not letting you know. No, I’m sorry, I couldn’t use either of your suggestions. Custom reports are too expensive for a selfhosted hobby blogger like me.

As for “search”, a) it seems like a messy way to identify topics (how to differentiate between “This post is not about Postfix” from “#postfix”?) and b) I simply couldn’t find said functionality in matomo reporting tool.

To be clear: I found that I could create goals that would respond to a string in a title, but there is no guarantee that the relevant tag or category names are found in my headlines. And “Contents” (under “Behaviour”) sounded like it could be useful but then I would need to somehow link it to my tags and I couldn’t see any way to do that.

tl;dr: I guess I will just do without. I will mark it resolved, seeing as I got answer to my question (“Is there a way to…”)

• This reply was modified 2 years, 6 months ago by brokkr.

Hi Yadav,

Yeah, I know what the CSS is. The point is that to make that change permanent, I would need to resort to child themes (or find some way to add old-school “additional css” on top of the theme’s css). And as I said, that does not feel like the right solution anymore.

• This reply was modified 2 years, 11 months ago by brokkr.

Yeah it seems that alt-shift-c centers the paragraph in addition to applying the code formatting. Other than that it works fine. Thanks, pkgw.

That fixed it. Excellent. Thank you so much ??

Just to be specific: It started working as soon as I changed the options in the table allocated to the problem subsite (“[network name]_2_options”). I will obviously change the ‘https://…’ values in the sitemeta and the main site options tables as well, but those values were not the cause of what I was seeing.

I seem to recall that that settings only applies to non-multisite setups. There aren’t any https options in settings / general, neither in the network settings nor in the individual sites settings. At least, none that I have found.

I’m not running any plugins on either site at the moment but Jetpack.

For wwhat it’s worth, I remember that the question of mixed content has come up before. When 4.4 came out about a year ago I and many others had some issues with WP not setting srcset links on images to https while the src attribute was. The solution proposed by developers at the time was to add some code to your theme’s function.php.

(Thread is here)

I believe that they have fixed that since, though, and in any case srcset wouldn’t apply to anything here, I’m thinking. Also in switching away from the custom theme as part of the troubleshooting those functions.php alterations are no longer in play. The blog runs on vanilla Twenty Sixteen.

Could there anything similar at play here?

Just to clarify what I’m seeing in the console.

• This reply was modified 8 years, 2 months ago by brokkr.

Got it. The connections are being blocked by the browser because of mixed content!

If I disable Firefox blocking mixed content I’m allowed access but nginx is set to redirect http to https with a 301 so I still get nothing, understandably.

Now, the question is still why this happens on one set of sites but not on the other. The certificates in question are obviously set in the name of the main domain but apply equally to the subdomains (named, not wildcard).

Here’s the certificate as represented by digicert’s cert checker:

Common Name = brokkr.net
Subject Alternative Names = brokkr.net, games.brokkr.net, sky.brokkr.net
Issuer = Let's Encrypt Authority X3
Serial Number = 0335C4899ED2AC8383E4DDDAF3BF797682EE
SHA1 Thumbprint = AFA557F0E01A01498CF66AA9F96B08CFFE6E48F6
Key Length = 2048
Signature algorithm = SHA256 + RSA (excellent)
Secure Renegotiation: Supported

Thanks for the suggestion. I feel stupid for not thinking of disabling plugins first.

Sadly, either that’s not it or somehow the cache is still on despite the plugin being gone. The page source files certainly no longer mention Comet Cache.

Here’s what I did:

I am not a (Comet Cache) Pro user so I never had that option to enable. CC Changelog says it’s exclusive to Pro, not ‘lite’. Also not an Apache but an Nginx user so don’t know what impact that would have had, even if.

In any case if the problem was related to CC, I figured that disabling the plugin should do the trick. It didn’t. Then I reenabled it, wiped the cache, disabled it. Still no go on either /wp-json or Jetpack features. So I deleted the plugin. Nope.

I disabled all plugins network-wide except Jetpack. Still no difference. Restarted nginx just for good measure. Nah. Switched theme to vanilla twenty sixteen in case there was anything in functions.php in the way. No. Still won’t let enable/disable anything.

I’m out of ideas :/

• This reply was modified 8 years, 2 months ago by brokkr.

Thanks for responding.

I get 404s on all sites:

{“code”:”rest_no_route”,”message”:”No route was found matching the URL and request method”,”data”:{“status”:404}}

This applies to both main site and subsite, e.g.

• https://games.brokkr.net/wp-json
• https://brokkr.net/wp-json

I have tried searching for explanations relating to wp-json (I’m assuming here that Jetpack makes use of it somehow now) but have not come upon anything. Some people do mention webser/proxy configuration so it might bear on the matter that I use nginx. I can’t see anything differentiating the sub and main site in the configuration of the server.

However, there are differences in what appears in the access logs. This is me enabling Tiled galleries on the main site:

86.52.239.162 - - [12/Jan/2017:21:15:44 +0100] "GET /wp-json/jetpack/v4/site HTTP/1.1" 400 122 "https://brokkr.net/wp-admin/admin.php?page=jetpack" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0"
192.0.101.132 - - [12/Jan/2017:21:15:46 +0100] "POST /xmlrpc.php?for=jetpack&token=U1bXlkHoiE2WgU%29Sx%4016014Gga%26B%5E0RP%3A1%3A0&timestamp=1484252135&nonce=kitAskjXaU&body-hash=BlirtvkZK6gLGJW6I0aTLi%2FbAbE%3D&signature=uT5hiLqsid5ONdHSuBZZWHKoLoQ%3D HTTP/1.1" 200 669 "https://brokkr.net/xmlrpc.php?for=jetpack&token=U1bXlkHoiE2WgU%29Sx%4016014Gga%26B%5E0RP%3A1%3A0&timestamp=1484252135&nonce=kitAskjXaU&body-hash=BlirtvkZK6gLGJW6I0aTLi%2FbAbE%3D&signature=uT5hiLqsid5ONdHSuBZZWHKoLoQ%3D" "Jetpack by WordPress.com"
86.52.239.162 - - [12/Jan/2017:21:16:04 +0100] "POST /wp-cron.php?doing_wp_cron=1484252163.8947679996490478515625 HTTP/1.1" 499 0 "https://brokkr.net/wp-cron.php?doing_wp_cron=1484252163.8947679996490478515625" "WordPress/4.7.1; https://brokkr.net"
86.52.239.162 - - [12/Jan/2017:21:16:05 +0100] "POST /wp-json/jetpack/v4/module/tiled-gallery/active HTTP/1.1" 200 87 "https://brokkr.net/wp-admin/admin.php?page=jetpack" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0"

Clicking the same slider button on the but site produces nothing in the access log.

I haven’t tracked it over time but I just noticed that on my most visited site Jetpack is reporting to have blocked some 15,000 attempts. So I don’t think you’re being targeted. Either Jetpack changed the way attempts are counted or – in all probability – somebody is just on a brute forcing spree. I tried news-googling ‘wordpress brute force’ and this came up:

https://www.bleepingcomputer.com/news/security/ukrainian-isp-behind-over-1-65mil-daily-brute-force-attacks-on-wordpress-sites/

If geo-blocking wasn’t such a dirty hack – and difficult to apply to something specific, like logins, not views – I would definitely consider it.

As for added features I wouldn’t hold your breath. Jetpack Protect used to be a separate plugin called BruteProtect which IIRC actually had some stats on the blocked attempts. So when you don’t get any info from JP Protect it isn’t because the feature hasn’t been added but because it’s been removed ??

Figuring that it might be possible to move all Jetpack admin to the network, I googled ‘Jetpack multisite network activate’ and came across this page which says that if Jetpack is network activated, the JP admin of the ‘primary site’ becomes the admin for the whole network – at least as far as Jetpack’s Protect feature goes.

Disabling subsite overrides and testing with the Tiled Galleries feature seems to confirm that this does not extend to other parts of Jetpack. The feature appears on the primary site but not on the subdomain sites.

Well, let me just say a big thanks to everyone. I had given up on this thread when Jeff Chandler over at WP Tavern wrote an article based on it ??

I too am using multisite, so the relevant settings are not found under ‘General settings’. However, inserting Joe’s code into the relevant (child) theme’s functions.php worked instantly.

Thanks again, marking resolved.

EDIT: Also apologies for double posting here and at stackexchange and thanks to birgire for posting another valid solution over there. I had given up on this after it seemed to go nowhere at first.

Well, a site with no images where images should be isn’t much good either ??

If this is intended behaviour, I can only see two ways to fix it:
* Use relative paths for all content (which I believe is also frowned upon)
* Disable the srcset attribute altogether
Am I missing anything?

As you rightly point out the lack of encryption off a few images aren’t a big deal. It’s just annoying that it causes the whole page to be termed ‘un-safe’. I like the plugin – and thank you for your work –
but that annoyance probably weighs heavier.

But I understand your reluctance to make such changes. I’m thinking that caching the images locally and then serving them from there could circumvent the issue but I suspect that that is outside the scope of a WordPress plugin – or maybe PHP in general – apart from possible copyright issues.

D’uh. I could of course just test my theory by removing the widget. And yes, that does remove the last unencrypted content from the page which is now given the all-encrypted padlock sign by Firefox.

So the question remains: Is it possible to get the ressources over https (i.e. are they availabe that way) and is it something that you might consider for the plugin?