Some thoughts on WordPress 5.0

WordPress Logotype

WordPress 5.0, also called “Bebo”, has been released recently. I think there never has been an update before that had to deal with so much criticism. Many people were alarmed, because the release date on December 6th felt a little rushed, with only a few days of notice beforehand. Also, the new editor, Gutenberg, still has a lot of Accessibility issues, although the WordPress Accessibility team and the Gutenberg developer team worked hard to eliminate as many problems as possible.

From my personal view as a web developer, I would advise against updating to WordPress 5.0 too quickly. I would suggest waiting at least until version 5.0.1 is out. Usually, after a release of a major update there will be bugfixes coming up in a short amount of time and the bigger problems will be eliminated shortly after the initial major release.
You don’t have to worry that your WordPress installation will update automatically to 5.0, since the auto-updates only work for minor releases (unless you have altered the configuration yourself).

WordPress 5.0 is not a security update, and the previous version 4.9.8 should continue to receive further security updates if needed, so there’s no big reason to update right away. If you’re using Wordfence, you will get alerts that your WordPress version is out of date, but in this case, it’s just an information – you can read their posting on this topic here.
Also, many themes that use their own layout builders for the content of pages and posts, still have compatibility issues with the newest version of WordPress.

There is a plugin called “Classic Editor“, which will enable using themes that don’t yet support Gutenberg. It is planned to be supported until 2021.

There is no need for you to panic, and you don’t have to rush things. I would advise you to try out WordPress 5.0 and Gutenberg on a development install, where you can safely play around, test your site and get used to the new WordPress version.

I am sure that WordPress will continue to serve as an easy to use Content Management System and that 5.0 and upcoming versions will include great improvements.

Welcome to the relaunched!


You have reached and a lot has changed here.

This website was started in 2006 by me, Stephanie Jagl-Posch. The aim was to support female action sports athletes by providing them with a platform where their news, photos and videos got shared.

I ran a personal blog separately, where I wrote about my own experiences as an outdoor enthusiast and amateur athlete.

In 2017, I was not happy with and my personal blog in their current form anymore. I was also looking for a place to share stuff about my job in the field of web development.

After taking offline and going on a hiatus from 2017 to 2018, I finally came to the conclusion that I wanted to strive towards creating a collective home for support for female action sports athletes, for my personal blog as well as for insights into the life of a web developer.

So here we are – I hope you enjoy your stay on my website!

My favourite button in Chrome DevTools: Pretty print!

Click to enlarge

A very practical option in Chrome DevTools is to show minified JavaScript files in their unminified, human-readable version. After opening up DevTools (STRG or APPLE +ALT + I), go to “Sources”, select the JavaScript File you wish to inspect. If it’s minified, DevTools will offer you the “Pretty print” (or “Format”) Button at the bottom below the code window, which looks like two curly brackets. Et voilà – the code will be displayed in an easier to read format!

WooCommerce – How to make the product quantity input field accessible

Screenshot of a code editor window with some PHP code visible

If you wish to improve the accessibility of the WooCommerce cart page, you may need to add a label to the product quantity input. To properly associate the label with the input, the input needs an ID.

Sadly, the used function woocommerce_quantity_input doesn’t come with the option to add an ID.
The solution is pretty simple though: There is a template for this input field, which you can copy to your own theme directory and alter.

The solution:

The path of the original file is:
Copy it to your theme folder, for example:

Then alter it like so:

<label for="<?php if ( isset($input_id) ) { echo esc_attr( $input_id ); } else { echo 'cartquantity'; }?>" class="screen-reader-text">
  <?php _e( 'Quantity', 'woocommerce' ); ?>

<input type="number" step="<?php echo esc_attr( $step ); ?>" min="<?php echo esc_attr( $min_value ); ?>" max="<?php echo esc_attr( $max_value ); ?>" name="<?php echo esc_attr( $input_name ); ?>" value="<?php echo esc_attr( $input_value ); ?>" title="<?php echo esc_attr_x( 'Qty', 'Product quantity input tooltip', 'woocommerce' ) ?>" class="input-text qty text" size="4" pattern="<?php echo esc_attr( $pattern ); ?>" inputmode="<?php echo esc_attr( $inputmode ); ?>"
id="<?php if ( isset($input_id) ) { echo esc_attr( $input_id ); } else { echo 'cartquantity'; }
?>" />


Now you can pass an ID to the input field by adding the argument input_id to the woocommerce_quantity_input function:

$product_quantity = woocommerce_quantity_input( array(
  'input_name' => "cart[{$cart_item_key}][qty]",
  'input_value' => $cart_item['quantity'],
  'max_value' => $_product->backorders_allowed() ? '' : $_product->get_stock_quantity(),
  'min_value' => '0',	
  'input_id' => "cart[{$cart_item_key}][qty]"
), $_product, false );


Why did you have to go and make things so complicated?

You may wonder why I used a variable for the ID. The reason for this is the cart page: Here you may have multiple products, which all have this quantity input field next to them. If we used a simple string as an ID, we would have multiple elements with the same ID, which is not semantically correct HTML and hinders screen readers from finding the correct input to associate the label with.


Thanks to Kathy aka helgatheviking for the helpful comment which led me to this solution.

Simple image modifications using Imagemagick in the shell

Screenshot of a code editor window with some PHP code visible

During the We Are Developers Conference in Vienna this year, I heard an interesting talk about “Habits of Efficient Developers”, held by Daniel Lebrero (the slides from this talk can be found on his website).

One of the key take-aways for me was that efficient developers automate all the things… well, at least the tasks they do over and over again.
Of course, I also have tasks that come up in nearly every project, so I have been thinking about a way to automate those tasks.

One of the first tasks that I chose to enhance was simple image modifications. I often need to do minor adjustments to images and don’t want to fire up Photoshop for that. If it’s just resizing, I’ll simply use the Preview app on Mac OS X, but placing a rectangular image on a square background is something that the Preview app can’t do.

So I came up with the idea to use a command line tool for this task – Imagemagick.

I installed Imagemagick with the help of Homebrew:
brew install imagemagick

Next, I needed a command for placing my image onto a square background, StackOverflow to the rescue!

magick convert -background white -gravity center /Users/stjagl/Desktop/originalfile.png -extent 500x500 /Users/stjagl/Desktop/squarefile.png


That’s it. In the timespan that would be needed to start up Photoshop, my image convertion will already be done.

Potentially upcoming feature for Google Chrome: Color Contrast Debugger

Screenshot of a code editor window with some PHP code visible

A potentially upcoming feature could making testing website accessibility even easier in the future: Google Chrome Canary offers the possibility to enable the experimental Color Contrast Debugger feature:

Simply clicking on the element reveals information about the contrast levels between background and foreground color and if they fulfill the requirements of WCAG 2.0 Level AA (expandable to show the compatibility with Level AAA).