Trackserver v2.0 released
This evening, I released Trackserver version 2.0. If you don’t know what Trackserver is, please read my introductory post.
The v2.0 update contains many changes and some interesting new features:
- It is now possible to add multiple tracks to a single map, by giving a comma-separated list of track IDs to the
trackparameter of the[tsmap]shortcode. You can also mix static tracks and live tracking in a single map, for example[tsmap track=12,84,live] - For maps with
track=live, an information bar can be shown at the top of the map with some data about the latest track point. Addinfobar=yesto the shortcode parameters. The content of the infobar can be formatted using a template that can be specified in the Trackserver user profile. - Experimental support for the SendLocation iOS app. This has not yet been tested with the actual app, but it works in theory. Please test this if you own an iOS device and a willing to spend the 99 cents for the app.
- Upload via the WordPress admin and HTTP POST now accept GPX 1.0 files in addition to GPX 1.1. It seems that some modern software (most notably Viking) still creates GPX 1.0 files 🙁
- The Leaflet JavaScript library was updated to v0.7.7 (a minor update)
Some bugs were fixed too:
- The track management page in the WP admin gained a lot of speed through some indexes on Trackserver’s database tables.
- Fixed a bug in the handling of OsmAnd’s timestamps, that caused an integer overflow on 32-bit systems.
Under the hood, there were some changes too.
Trackserver is now capable of using GeoJSON, rather than Polyline encoding, for getting tracks from the server to display them on a map. However, the benefit of this is somewhat limited. GeoJSON is human-readable (sort-of) but it is also a multitude bigger than Polyline, so for performance reasons, the default is still Polyline.
Trackserver has always tried to determine whether its JavaScript files (including those belonging to Leaflet and its plugins) are necessary on the current page, and to not load them if they are not. It appeared that there are quite a few possible ways in which this detection mechanism could fail, and maps could not be displayed even though they should. Version 2.0 has two ways to mitigate this problem.
First, there is the new [tsscripts] shortcode, that forces Trackserver to load its scripts and CSS, even though the [tsmap] shortcode is not detected. Use this if all else fails. Second, there is an alternative detection algorithm, that can detect the use of the [tsmap] shortcode much more reliably (should be 100%) but has the disadvantage that Trackserver’s CSS cannot be loaded in the <head> of the HTML document anymore. So, neither solution is perfect and that’s why they’re both there.
The technical background story to this problem is, that some WordPress plugins and themes use custom WP_Query objects. This means that the actual list of posts to be displayed can be totally different than what WordPress initally thinks it should be. The initial shortcode detection can only look at the initial query, so any changes that add or remove posts from the query will surely confuse the detection algorithm. The alternative detection just uses the actual shortcode handler to initiate the inclusion of Trackserver’s JavaScript and CSS, but since this handler runs during the rendering of the page, long after the <head> section is printed, the CSS is loaded very late in the document. I am not sure whether this is a big problem, but opinions seem to differ on the subject, and loading CSS in the <head> is still best practice, so Trackserver will try to do that whenever possible.
Please test Trackserver v2.0. If you find any problems, please open a support ticket on the plugin page, or open an issue on Github.
And here’s a map for you 🙂
