How would you approach the markup and the CSS regarding the buttons below when given the following mockup?

How would you approach the markup and the CSS regarding the buttons below when given the following mockup?
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.
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.
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:
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.
Hope this helps to someone.
Upgraded to Webpack 2.x beta and don’t see your source maps for production build despite devtool
value seeming correct? Fear not, most probably you haven’t configured your UglifyJsPlugin
plugin right – check whether its configuration contains { sourceMap: true }
option. This has changed by default to false
to speed up the compilation.
Nevertheless, I find Webpack 2.x very, very pleasant, programming with System.import
is a joy.
Hope this helps to someone.
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:
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.
Deferred loading of resources can tremendously increase the percievable load time of a web page. That can be easily done with Javascript files which is described here or with HTML5’s async attribute.