Timeout at getCurrentPosition in Cordova app on Android

I made a simple Cordova application that wraps the web site of a client. The app asked for the current location using the “official” Geolocation plugin (cordova-plugin-geolocation), but it turned out quite unstable on Android. Sometimes it just stopped providing location. Someone suggested rebooting the phone as a fix, which did help, but is not a very good solution in the long term.

Somewhere I saw that Google suggests using its Play Services API for getting the location, instead of the vanilla Android API. Then I found Google Location Services for Cordova plugin that uses the Play Services location API. Somebody in Stack Overflow suggested that too. The original geolocation plugin gets its location from the webview, which I suppose gets it from the vanilla Android API.

Because the Google Location Services plugin is naturally for Android only, I still use the geolocation plugin on iOS. Here’s the code that uses the Google Location Services plugin if it exists and the default one otherwise:

var locationService = navigator.geolocation;
if (cordova && 'plugins' in cordova && 'locationServices' in cordova.plugins) {
  locationService = cordova.plugins.locationServices.geolocation;
  console.log('Using cordova-plugin-locationservices');
}

locationService.getCurrentPosition(
  function (position) {
    var positionStr = position.coords.latitude + ',' + position.coords.longitude;
    console.log('Got position: ' + positionStr);
    // ...
  },
  function (err) {
    console.log('Did not got position: code=' + err.code + ' message=' + err.message);
    // ...
  },
  {
    enableHighAccuracy: false,
    maximumAge: 30*60*1000, // 30 min
    timeout: 20000 // ms
   }
);

Issue with WordPress text widget, Black Studio TinyMCE Widget and icl_sw_filters_widget_text

We had a problem where the text of plain old WordPress text widgets was not showing on pages. Error log showed entries like

[13-Dec-2017 09:25:29 UTC] PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'icl_sw_filters_widget_text' not found or invalid function name in /home/itukylat/public_html/wp-includes/class-wp-hook.php on line 288

Function icl_sw_filters_widget_text is defined in WPML String Translation plugin, but we didn’t have that installed. The only place where I could find hook to icl_sw_filters_widget_text being added is in Black Studio Tiny MCE Widget plugin, in black-studio-tinymce-widget/includes/class-compatibility-plugins.php, function wpml_widget_after:

if ( false === has_filter( 'widget_text', 'icl_sw_filters_widget_text' ) && function_exists( 'icl_sw_filters_widget_text' ) || version_compare( $this->wpml_get_version(), '3.8.0' ) >= 0 ) {
    add_filter( 'widget_text', 'icl_sw_filters_widget_text', 0 );
}

and indeed that gets called, even though there is no icl_sw_filters_widget_text function anywhere.

I suspect there is something wrong with the if statement, but I didn’t dig any deeper. But I did report the issue to Black Studio Tiny MCE Widget author.

Meanwhile, as a workaround I defined my own icl_sw_filters_widget_text function:

function icl_sw_filters_widget_text($text) {
    return $text;
}

Now the texts in text widgets show up again.

Workaround for gitlab-runner issue #2408 “Cannot connect to the Docker daemon”

TL;DR; Change your pull policy to “if-not-present” or “never”.

Our Continuous Deployment pipeline at Wysiwyg worked fine, until it stopped working. It started giving errors like this:

Pulling docker image registry.gitlab.com/wysiwygoy/dev/cd-deploy ...
ERROR: Preparation failed: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

A bit of googling resulted in gitlab-runner issue #2408. I tried some of the suggestions in the thread but couldn’t get it working.

Finally I found a workaround: Because it fails when pulling my custom image from gitlab.com registry, I changed the pull policy of the runner (in config.toml of the runner) to “if-not-present”. The executor then skips pulling the image and executes its actual job just fine.

I suspect that gitlab.com registry responds too slowly and the docker client library gives up with the error mentioned above.

The downside of course is that if I update my executor image I need to pull the new image manually. In practice it doesn’t happen that often, so I can live with that until the fix to gitlab-runner is in.

I posted my finding as a comment to the issue.