Sulby Theme Slider
February 23, 2018
I built this simple slider for my standalone
In several past projects we used a well known third-party slider. Now I wanted something more minimal, lightweight and extensible. If we want to change the look and feel then we can do that that in CSS. If we want different functionality then let’s do it in the code. It’s much simpler than trying to work out how to achieve a result via a convoluted plugin interface or restrictive settings.
The PHP creates a WordPress Shortcode. The WordPress Shortcode API can be used to create macros which can be added to a Post or a Page – or to a PHP template using the
do_shortcode() function. Eg the slider shown here is added like this:
[insertSulbySlider images=1005,992,1003,1002,993 message-title="Slider Demo" message-body="stock images from my legacy portfolio at Getty Images & iStockPhoto" slider-caption="Bunhill / Getty Images" slider-caption-link="https://www.gettyimages.com/search/photographer?excludenudity=true&family=creative&phrase=bunhill&photographer=bunhill&sort=best" delay=8 aspect-padding=56.25 header-bool=false]
The images are added by ID. The
$custom_aspect variable allows me to specify the aspect ratio of the slider. The TL;DR:
eg – 100 = 1:1 / 75 = 4:3 / 66.66 = 3:2 / 56.25 = 16:9
We need to be able to specify the aspect ratio every time. The slider is a div background image but there is not currently a way in CSS to set
height such that it is dynamically proportional to
calc only works with
width to 100% and
height to 0 (in the CSS). Then use padding-top as a percentage. The method is described here at w3schools.com.
$header_bool variable flags a specific exception – if the slider is at the top of the page then it wants to be approaching full height relative to the device or browser window –
$custom_aspect variable is effectively ignored.
Each slider needs a unique #ID – because elements must be unique per page and potentially we may have more than one slider per page with different properties. That means naming them dynamically. PHP’s
uniqid() is a perfectly adequate solution here.
WordPress Customised Data Entry Interface – PT2
December 18, 2017
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
WordPress Customised Data Entry Interface – PT1
December 16, 2017
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:
[ Product ] is a
Custom Post Type. I also created additional
Custom Taxonomies for fields which would potentially need to be searchable using
WP_Term_Query. This is a rather simplified version of what I successfully implemented – the client version included several additional
[ 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.
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.
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:
This is how the AJAX side of that is implemented back in the PHP:
Finally saving [ Product Version ] – called on post: