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.
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.
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.
So, you like how Facebook, Twitter, and other sites don’t break their content into pages. You’ve researched the technique and found out it’s elegantly named “infinite scroll”. Hopefully you did some reading and weighted the pros and cons for your own use-case. Finally, you decided that you want it on your WordPress blog. Of course, there are infinite solutions out there that will get your job done, but probably the easiest one is the one that Jetpack bundles. There are good chances that you theme already supports Jetpack’s Infinite Scroll, but you wouldn’t be reading this if it did, would you?
We all know and love WordPress widgets, both core and third-party. They give us and our customers the flexibility to “build” specific areas of a website dynamically, displaying anything we choose from an array of available options. This fact was even more important before page builders became prevalent, and may be overshadowed by the coming of Gutenberg, but for the time being, widgets are an integral part of WordPress.
There are times however, that we may need to restrict the selection of available widgets, rather than expand it. Perhaps a widget is irrelevant, or it causes more problems that it solves. Instead of trying to warn or educate your users about potential issues, something they (and you) will ultimately forget, you may opt to completely remove the widgets in question.
WordPress stores user information out of the box, and it cares for the user’s name, email, and some more basic info, it leaves a lot to be desired. For example, social network links are pretty-much required these days, but since social networks come and go on a daily basis, WordPress itself can’t commit to supporting any single one as it may not exist tomorrow. A user’s date of birth is quite important for some websites as well (for example, with age-restricted content), however since a user’s date of birth may be considered confidential or identifying information, it may be illegal (or require special permits) in some countries. Again, WordPress won’t collect this information by itself in order to give us (its users) the freedom to use it no matter of our location. It therefore provides the means to build support for this extra information ourselves.
Your website’s speed matters a lot, because when your site is slow, your visitors will quickly go away and look for a competitors site that doesn’t waste their time. But computers are fast. Very fast. Yet, there are operations that are computationally intensive, network latency that increases access times, or complex database queries that can bring a even a powerful server to its knees. In such cases, a level of caching should be implemented where possible, so that a stored, pre-computed result is served to your visitors. When will this cache get refreshed is a matter of use-case, but as a general rule of thumb, it should be updated as rarely as possible.
Do you build a plugin and want to easily display some general information? Or perhaps you are building a theme and want your customers to keep up with your blog? If you don’t want to build a dedicated settings page, then a simple (or complex, your call) widget on the WordPress dashboard should be enough. It’s very easy and very fast, too!
Do you need to show an extra navigation menu on your WordPress site? Or perhaps you need to show a bunch of links someplace? No matter your use-case, WordPress provides navigation menus that are very easy to create, manage and display. If you like the drag and drop interface of the navigation menus management screen, and you so you figured you’ll create a menu to show them.
However, you neither want to show them in the sidebar (“Custom Menu” widget), nor in the content (“menu shortcode” plugin), and your theme doesn’t quite allow you to display it exactly where you want. What do you do? You need to register a new menu location. Let’s see how.