Have you ever wanted to know how to build your own WordPress widget? Have you ever wanted to know how you can use (consume) a third-party API from within your WordPress theme/plugin? Did you answer “yes” to at least one of the questions? If you did, the keep reading because you’re actually learn how to do both.
If you have a WordPress site and are interested in selling anything, WooCommerce is most likely the way to go. Powered by Automattic, it is by far the most popular e-commerce plugin available for WordPress. It is supported by a very large community and it’s extended with themes and plugins by many third party authors.
Listing templates are every WordPress theme’s bread and butter. Every type of content needs to be displayed somehow and listing templates are the norm when it comes to showcasing content that falls within the same family, i.e. posts, pages, products, or any kind of other custom post types. We use them extensively here at CSSIgniter with a lot of options like headings, animations, post meta visibility, and more. Our main and most wanted option though is the column number setting, i.e. choosing in how many columns to split the cards each post is contained within.
Have you ever tried setting up a multilingual WordPress site? If you did, you’ll know it’s no easy feat. You need to translate WordPress-provided strings (okay, these are mostly already translated by the time a new version is released), theme strings, plugins strings. You’d do that with a tool such as Poedit or a WordPress plugin such a Loco Translate (let’s call them “translation plugins”). But then there’s also the dynamic strings, a.k.a. the content. All those words you write yourself through WordPress. Posts, pages, custom fields, widgets, etc. These need a separate kind of WordPress plugin (let’s call them “multilingual plugins”), able to extract them, translate them, and show the appropriate translations depending on the user’s choice of language.
Gutenberg itself already exposes a lot of components ready to be re-used in our custom blocks. Most of these are located in
wp.blocks, and they include helpful building blocks for every Gutenberg block: Text Controls, Toggles, Tooltips, Icon Buttons, Tabs, and many many others. Gutenberg’s native component library pretty much has us covered on all basic cases, on every kind of basic UI control we might need but still there are cases where we might need to take it a step further on some kind of more specialized custom block.
As theme authors we’re always striving to give our themes a unique design and marry them to the WordPress ecosystem by trying to provide a unified user experience, to the best possible extent. As WordPress comes with its own widgets, shortcodes, and other components, it’s important for any theme to take them into consideration and style them accordingly to its look and feel.
I can’t stop praising WordPress when it comes to the conveniences it provides. While the approach it takes on things might not suit everyone, every time, for the most part its solutions to common issues are good enough. Once such example is images, and the creation of custom sizes from the originally uploaded one.
WordPress goes to great lengths in order to provide us with a localized environment, displaying dates and times in the correct format and even language. However, since it uses its own timezone setting, some native PHP functions are no longer applicable (or don’t return correct results), such as the date() function which returns a date/time string depending on the timezone configuration of PHP itself, ignoring the WordPress setting.
With Gutenberg getting close to being ready for a beta release and ultimately being merged into core WP, its API and patterns are at a level mature enough that theme authors (and theme shops!) can start planning ahead for the inevitable adoption of the new block system.
In this post we’ll see what the average theme author should have in mind when updating a theme for Gutenberg compatibility and ponder about the future in theme and plugin editing.