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.
Star ratings are a quick and simple way to get feedback from your users, that’s why it has become so popular all around the web. Today we’ll extend WordPress comments by adding our own star rating system.
One of the greatest things about WordPress, is undoubtedly its customizability. Not only it provides various APIs to make our lives easier by abstracting and hiding complex code and processes, but also allows us to intervene and modify its default behavior. It also gives us the ability to provide the same level of customizability in our own code. If you’re regularly reading tutorials about WordPress or you’re tinkering with PHP, chances are you’ve come across and interacted with hooks.
Gutenberg comes with a set of core libraries which are necessary for any kind of custom block development. Namely those libraries are:
- @wordpress/components: Generic, reusable UI WordPress components
- @wordpress/i18n: Internationalization utilities
- @wordpress/element: Abstraction on top of React
- @wordpress/date: Date formatting and manipulation utilities
- @wordpress/blocks: Module providing utilities for registering and building blocks
- @wordpress/data: Abstraction on top of Redux
- @wordpress/editor: Module representing the WordPress Editor’s page
- @wordpress/utils: Various generic utilities
To use them you need to include them as external script requirements to your final build by registering and enqueueing them, similarly to how you’d include any kind of script or style within WordPress.