Michael Adams (mdawaffe)

This has been fixed in the in-development version of Jetpack: https://plugins.trac.www.ads-software.com/changeset/587002

I’m not sure when the next bug fix release will be, but my guess is sometime next week.

We’re fixing the inconsistencies now; thanks for bringing them to our attention.

A few notes, though.

1. get_permalink() should always return the canonical URL of your page. If you have some custom setup, you should make sure get_permalink() reflects that.
2. Jetpack’s ::get_link( $url, ... ) really should be using get_permalink(). Those links take the visitor to a page hosted on your site (and generated by Jetpack), which then redirects to the correct sharing service. That redirection is typically handled in ::process_request(). So it’s the code in ::process_request() that should be using the sharing_permalink filter, not the code in ::get_link() (usually).
3. Twitter defines the “counturl” as the URL the shared URL resolves to. That is, if you share a shortlink (bit.ly, for example), you would pass the canonical URL as the counturl. As I mentioned above, the canonical URL is the result of get_permalink(), so the counturl code is correct.

So our fix may not be exactly what you’re looking for ?? It sounds like you’ll still have to write a baby plugin for your site that fixes the results of get_permalink() for your page.

Thanks for letting us know about the problem. We think we have the issue fixed and will release a new version shortly (no specific ETA) with a fix.

When you say it crashed, what did you see? Just a white screen?

Do you have access to your PHP error logs?

The bug on our end should be fixed now. I’ve tried nb_NO, it_IT, and da_DK and all are getting translated correctly.

Note that translations aren’t complete for some languages because the strings have not been translated at https://translate.wordpress.com/projects/wpcom

There are three things going on here.

1. Jetpack needs to have everything translated: https://translate.wordpress.com/projects/jetpack
2. The comment form is loaded in an iframe from WordPress.com, which is translated separately from Jetpack: https://translate.wordpress.com/projects/wpcom
   We try to make sure that the strings WP.com and Jetpack have in common get synced correctly, but not all the strings are the same between those two translation projects (and sometimes we miss some). So if you see a string untranslated in the comment form, make sure it’s translated in the wpcom project as well.
3. There’s a bug ?? Some languages/locales don’t get correctly set in the Jetpack comment form. nb_NO is one of them. We’re fixing this bug right now. When it’s fixed, it will “just work”, there will be no need to get a new version of the Jetpack plugin.

Jan Dembowski, thanks for the tip! You’re right: we currently don’t support the Unicode representation of IDNs. We should ??

We’ll working on supporting them. For now, though, ASCII is the way to go.

Sounds like most of the issues here are resolved, but there were a couple other bugs this menu madness caused.

In 1.3.4, we ended up going back to the old behavior for now: Clicking the top level Jetpack menu takes you to Jetpack (not stats).

So many releases! ?? Thanks very much, everyone, for letting us know about these bugs so we could address them quickly.

The reason these bugs exist is because we’re trying to do make the Stats page (what most want people look at) what you see when you click on the Jetpack+Stats top level menu.

There’s a bunch of edge cases, though, so we have to be “clever” in how we do it.

Apparently, we haven’t found all the edge cases because we don’t yet know all the things to test for. We’ve been releasing like mad to try and fix the bugs you report, but it looks like this experiment is at best half-baked, so we’ll probably revert to the old behavior: When you click the Jetpack top level menu, you’ll see Jetpack, not stats.

Stay tuned.

We’re working on a fix now. Thanks for your patience.

I tried hard to reproduce this problem, but couldn’t manage.

I have Windows 7 and IE9. I downloaded the free trial of Trend Micro? Titanium? Maximum Security 2012.

I let Trend Micro update itself, then loaded a Jetpack blog’s stats page, which was the only place I could see load-scripts anywhere (though it’s load-scripts.php not load-scripts.js). I got no warning. I then ran a full scan from within Trend Micro and it found nothing.

I’m pretty sure this is a false positive on Trend Micro’s part, but without being able to reproduce the problem, my only suggestion is to contact Trend Micro and see what they have to say.

Sorry we missed this thread. We’ve never heard of this problem before.

There is code in Jetpack to clean up these nonces already; it runs on a WP Cron hook.

For those of you experiencing this problem, do other WordPress functions that depend on WP Cron function? For example, are you able to schedule future dated posts and have them appear automatically at the scheduled time?

Thanks for your help in fixing this problem.

Could you paste the full error message. A screenshot would be helpful as well.

I’m almost sure this is a false positive, but we’ll look into it if you can provide the full error.

Thanks for letting us know.

I didn’t think you were accusing anyone. I hope you don’t think I’m making accusations either ??

We’re just trying to get to the bottom of it too.

Both scripts take about 10 seconds before failing. 10 seconds is the timeout for both connection and data transfer in the remote request.

To see which phase is failing, you could set one of the timeouts to 5 seconds. Set CURLOPT_CONNECTTIMEOUT to 5, for example, in both scripts.

It should be possible to figure out from the strace too.

Another good test would be to edit the script to make a remote request to example.com or google.com or something other than jetpack.wordpress.com.

Then, if the script still fails, it’s clearly not the fault of jetpack.wordpress.com ?? It must either be a problem with your host or the script itself.

Our servers respond to a lot of requests, so I don’t think the resource limitation is on our end. It seems more likely that your host is limiting the resources available to any given user or process. Maybe an open file descriptors limit?

You can send the full strace to https://en.support.wordpress.com/contact/?jetpack=needs-service if you want me to look at it.

Mention me (mdawaffe) and let me know here if you do that so I can look at it promptly.