Google Maps: from XML with Marker Clustering

January 2, 2018

#Google Maps #HTML5 Geolocation #JavaScript #jQuery #Marker Clustering #PHP #Shortcode API #WordPress #XML

 

This is something I was working on recently. We wanted to use Google Maps to show the location of the client’s many distributors and agents. And we wanted to implement marker clustering. You can use the MarkerClusterer library in combination with the Google Maps JavaScript API to combine markers of close proximity into clusters, and simplify the display of markers on the map. Zooming in you begin to see the individual markers on the map. Zooming out of the map consolidates the markers into clusters again.

I have defined the markers as XML elements with properties defined as attributes. Apart from latitude and longitude – the other properties define how I have chosen to implement the Info Windows – what a user sees when they click on a marker. In this example simply the business name, address and telephone number. But an Info Window can potentially provide much more detailed or layered information. Obviously in a real implementation of this example the name and address info would be different for each marker:

... <marker name="Business Name" address="Street Address Line 1, Street Addresss Line 2, City, Country, Code" tel="+XX 123 456 7890" lat="-36.7624557" lng="144.2874504" /><marker name="Business Name" address="Street Address Line 1, Street Addresss Line 2, City, Country, Code" tel="+XX 123 456 7890" lat="51.555386" lng="5.082930000000033" /><marker name="Business Name" address="Street Address Line 1, Street Addresss Line 2, City, Country, Code" tel="+XX 123 456 7890" lat="51.2164861" lng="4.4046062" /> ...

I am using the browser’s HTML5 Geolocation feature to attempt to locate the user on the map. That’s going to be confusing if your corporate network is routed through another jurisdiction. The user will be asked to allow the site to use their position. NB: Browsers including Chrome no longer support obtaining the user’s location using the HTML5 Geolocation API from pages delivered by non-secure connections. This means that the page making the Geolocation API call must be served from a secure context – eg HTTPS.

In this example I have implemented the map using the WordPress Shortcode API. We can simply add [insertSulbyMap] to the page or post where we want it. But it could equally be contained as a plugin or coded into a PHP template (which is how I did it in the version we built for the client).

The takeaway from this, for me, was that it was simple to code my own implementation using the Google documentation. Better than being an additional third party dependency by using a commercial plugin. Google already make it easy.

WordPress Customised Data Entry Interface – PT3

December 20, 2017

#JavaScript #jQuery #PHP #WordPress

The Custom Taxonomy [ Product Line ] is itself an entity and has 2 additional fields – for a PDF and an image to be attached – ie in the case where a single PDF and image is applicable to all products in a particular line.

WordPress has hooks to achieve this. In each case we use _add_form_fields, _edit_form_fields, created_product_line and edited_product_line. Not forgetting to santitize the input before writing it to the database.

Additional fields added to the Custom Taxonomy
Additional fields added to the Custom Taxonomy

Show Code

WordPress Customised Data Entry Interface – PT2

December 18, 2017

#AJAX #JavaScript #jQuery #JSON #PHP #WordPress

Our [ Product ] entity is as a Custom Post Type. Looking at the list of product items, we want to be able to choose which fields are shown as columns. We can simply achieve this result by combining manage_{$post_type}_posts_columns & manage_{$post_type}_posts_custom_column

simple data model
Custom [ Product ] listing – selected fields only shown here

Show Code

WordPress Customised Data Entry Interface – PT1

December 16, 2017

#AJAX #JavaScript #jQuery #JSON #PHP #Relational Models #WordPress

The client needed a customised backend for a WordPress site to facilitate data entry for a small catalogue of products (fewer than 100 items in total). There were 3 different specific types of product over multiple lines.

Clearly we need to begin by establishing a logical data model. The entity relationships look like this:

simple data model
Simple data model

[ Product ] is a Custom Post Type. I also created additional Custom Taxonomies for fields which would potentially need to be searchable using WP_Query or WP_Term_Query. This is a rather simplified version of what I successfully implemented – the client version included several additional taxonomy fields. [ Product Type ] and [ Product Line ] are logical entities. [ Product Version ] is arguably just a grouping of [ Product ] fields. We don’t actually need to worry about that distinction here – because of the way in which the underlying database structure is abstracted by the WordPress API.

Product - as a Custom Post Type
Product – as a Custom Post Type – with additional Custom Taxonomies
client products plugin
Client products plugin

In this case it made sense to separate the product catalogue functionality by coding it as a WordPress plugin. It comprises two files – the PHP and the JavaScript. With WordPress we can customise the backend user interface (the Dashboard) using custom meta boxes. The user needs to be able to enter the data for each field. As shown in the example here which is demonstrated with dummy data for an imaginary product. There is a good description of the metabox api at Theme Foundation’s WordPress Meta Boxes: a Comprehensive Developer’s Guide.

Custom Data Entry Interface
Custom data entry interface for [ Product Item ] fields
Custom Data Entry Interface
Custom data entry interface for [Product Item] fields

Some of those fields are just text boxes – the user can type in anything (though obviously that data needs to be sanitized before being written to the db). Sometimes the user will be selecting an image (or a PDF) from the Media Library (or uploading a new media item). Other times the user may selected from a predefined list (with radio buttons). Or the user may choose an item from a list where the option also exists to add a new item to the list.

When the user has completed or finished editing the fields for a product – then they publish, the same as any other post. But if a user is adding a new field item – for example a new [ Product Line ] then we want them to be able to do that without the need to reload the page in full. We use AJAX to update the database and the page. There is a good tutorial here at wpmudev.org – about how to implement and secure wp-ajax. Even with this being on the admin side, rather than user facing, it is important that the callback is properly secured. The following PHP shows how the metabox for [ Product Version ] is implemented:

taxonomy options
Taxonomy options

Show Code

Here is the corresponding JavaScript (jQuery). Any taxonomy which has an add button will use the same function. The client version has several additional similarly coded taxonomies which I am not including in this simplified example.

Show Code

This is how the AJAX side of that is implemented back in the PHP:

Show Code

Finally saving [ Product Version ] – called on post:

Show Code

1 2 3

Show All Posts