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

iOS Swift development

December 15, 2017

#Apple #iOS #Swift #Xcode

Lists App Icon

It’s been over two years since I looked at it because other projects came along. But I spent much of 2015 learning Swift – initially working through Developing iOS 8 Apps with Swift course on Stanford's iTunes U. I very much enjoyed being completely immersed in the code and concepts. During this period I was also fairly active on stackoverflow. Most of my questions and answers over there still relate to Swift. During that period the language was transitioned through various version 2 releases. Today I would almost need to start again. Especially given that syntactically it shares many similarities with other basically C – like languages. I used various different programming languages and environments over the years (including COBOL, Pascal, Basic, C, C++, Visual Basic, PHP, Javascript + jQuery). I feel that I only really know a thing well whilst I am fully involved in using it. It’s the patterns we remember most.

Lists is a Universal iOS app I built in in Xcode. 100% Swift – it was also an exercise to find out how to build and deploy an iOS app. The various generations of source code usefully document much of what I learned along the way. I built it using the UISplitViewController class with UITableViews. The split view adjusts automatically depending upon whether the app is used vertically or horizontally. Built using Auto Layout and Size Classes, the app resizes intelligently and is responsive to the type of device it is run on.

Simple One-To-Many Relationship
Simple One-To-Many Relationship

Early versions of the app persisted data using XML files. Finding out how to save and parse XML using Swift was a useful learning process but I quickly switched to using Apple’s Core Data framework. Core Data provides a layer of classes which encapsulate a variety of mechanisms including SQLite for persisting and querying data. Whilst various third-party alternatives exists, Core Data is a robust technology which offers the clear advantage of not risking 3rd-party dependencies.

The app synced via iCloud between iOS devices logged into the same account. My experience of this at the time was that it was not always especially reliable – this also seemed to be the opinion of much of the developer community. I got it mostly working – but then there would be unexpected glitches. Especially when using mobile data. Perhaps it is more stable today.

Device specific settings data were stored using NSUserDefaults – for example the need to know whether the app was being run for the first time after installation on any specific device. The app incorporated Twitter’s cross-platform Fabric framework for crash reporting and analytics. Fabric has since become part of Firebase, Google’s mobile development platform. The app was tested and tweaked (memory allocation etc) using Apple’s Instruments and distributed for beta testing via TestFlight.

 

Storyboard Layout
Storyboard Layout
Xcode IDE
Xcode IDE
1 2 3 4 5 6