Just another technical yaddayadda

Menu

Preface

WordPress is a fantastic CMS. Although very functionally rich, it also provides extensibility options via its plugin system. Sometimes it may not be enough though, one of the reasons for this may be that the functionality you’re looking for is too specific, so there’s no big incentive for someone to write a general purpose plugin for this.

Like my case, for example: duplicate featured image for every published post. There is no such functionality (“copy image”) in WordPress Media Library and I failed to find a WP plugin for this. Therefore I had to automate.

One of the ways how to do this is using XML RPC API provided by WordPress itself. I decided to use WP CLI though because it is a fantastic command line tool that works with Bash shell scripting. It is also a very useful admin tool, for example, for upgrading your WP plugins or the WP core install.

Copying Featured Images

So here’s the script:

What it does here, it uses the WP CLI tool to list all published posts in one list (--posts_per_page=-1, --nopaging=1), then it finds the featured image entry (which is also a “post” from WP perspective). Notice that we use the fantastic jq tool here to parse JSON returned by the wp command. The reason for this is, well, I could not figure out how to retrieve a single row containing the value of _thumbnail_id meta key.

Provided we have the actual thumbnail id ($mediaID) we find the actual URL of the image (guid field of the post object), download it locally and then just impor it back and attach to the very same post.

You (or someone else using particular WP installation) can the find all the duplicated images in Media library by searching for “Duplicate featured image” or “post id <your id here>”.

Of course, this script lacks some error detection, it also assumes that all images are in JPEG format etc etc., however I hope someone may find this useful.

Sometimes a reusable HTML/CSS component or fragment may look differently across various surroundings, and I personally have killed several hours trying to spot that (most probably one single) pesky little descendant selector that causes this.

The same HTML/CSS component under different parents

I’d like to share a very simple trick how to spot these problems using a modern browser with developer tools and some text diffing tool. Let’s assume we’re using Google Chrome, however Mozilla Firefox or Internet Explorer or Microsoft Edge could also do just fine.

First, open the first page/view with our component and open Developer Tools (Cmd/Ctrl + Shift + I). In Elements tab, select your element and type in Console: JSON.stringify(window.getComputedStyle($1), null, 2). window.getComputedStyle($1) returns an Object containing information of every CSS property (both explicitly defined and inherited) of the selected element ($1) and JSON.stringify with additional arguments (null, 2) formats this object as pretty-printed JSON string. Select and save this text to a file, say style-1.json.

Repeat the same process with the same element in another view, save your element’s style JSON text in another file, style-2.json.

Now open both files in a diff tool of your preference. I’m using WinMerge. You’ll spot the difference immediately, something like this:

CSS JSON diff sample in WinMerge

Now you see the exact CSS property that affects component’s layout, therefore can find out where particular rule that sets the property comes from.

Introduction

I might be wrong, but It seems that one of the main postulates concerning working with client side Javascript is that the fastest method for manipulating the DOM tree is using the non-standard although ubiquitous innerHTML property, opposed to standard DOM methods createElement, appendChild etc.

However, already back in 2010, Nicolas C. Zakas in his book High Performance Javascript, chapter “DOM Scripting”, has shown that this is not universally true: according to him, Safari 4 and Chrome 3 outperformed the assignment of the innerHTML property.

That made me thinking, what’s the state of the implementation of these approaches today, in 2013-2014.

TL;DR: Using Google Guice with its servlet extension, be very careful when adding your filters from nested modules. The filter chain order could be the opposite to that you might expect. When using Sitebricks, override SitebricksModule method servletModule, extend the returned SitebricksServletModule with overriden configurePreFilters, configurePostFilters, or configureCustomServlets methods.

Before I stood in the Java world with both feet, I’ve been having many doubts of how to do things in Java when programming web applications. I mean, Java is a general purpose language and one of its strengths is modularity. There are different modules (libraries) for accessing data – Hibernate, Eclipse Link -, presentation frameworks – Sitebricks, Wicket, Google Web Toolkit – and there are even dependency injection frameworks that help you to glue everything together, like String Framework or, my favourite, Google Guice. Not to mention the basic building blocks like Java standard library itself and all those JSRs.

No doubt, those who criticize Java are correct – the learning curve is pretty steep because, in contrast, other languages have frameworks that handle it all together – like Django for Python or Ruby on Rails.

I guess, there is no more discussion that the correct way of writing applications is to use layered approach instead of spaghetti coding everything together. Applications have:

a data layer,

a service layer,

and a presentation layer.

When coming to Java world, the hardest part for me was understanding how to program the service layer because, well, noone actually tells you how :).

I suppose, a very common use-case in any CMS is uploading a file, say, an image or a video. This task actually consists of two subtasks: enabling users to upload content, and ensuring that the same content can be viewed.

There can be various ways how to accomplish this depending on the setup and the whole system performance requirements, like serving the content from a separate web server for static content or even from a dedicated machine for just the static content only.