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.
Keyboard shortcuts, as their name suggests, are a great way of streamlining your work process when dealing with computers. WordPress comes with its own set of shortcuts to help content publishers be faster when writing, or editing content.
Useful shortcuts for the text editor
Most of you are familiar with the text editor toolbar sitting right there, above the text entry box. The toolbar hosts a number of very useful text formatting options like changing font weight, text alignment and more, you’ve seen them and most likely clicked them, right? Well, if you want to become quicker you don’t have to, just utilize the shortcuts listed below and you’re on your way to more efficient publishing.
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.
Ever since WordPress version 3.4 it’s been extremely simple to add site settings to our websites with the Theme Customization API. Here at CSSIgniter it’s actually been a couple of years now where we’ve completely abandoned custom Theme Options pages in lieu of the Customizer, since the benefits are too many to pass: ease of use, consistent API, native look and feel, and live previews to name a few.
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.
If you allow registrations on your WordPress site, chances are you need to gather some more information about your users. If you absolutely need this information, the best way to get it is to make it required during registration, otherwise there are slim chances that your users will actually visit their profile page and provide that optional information.
It’s been quite a while now since we’ve completely abandoned vanilla CSS for a CSS preprocessor (more than four years actually) and more specifically for Sass (with SCSS syntax). There are quite a few reasons why we did that, and the main one is improved DX (developer experience) along with easier plugin integrations.
Simply put, Sass used to be (and still is) a much more powerful language than vanilla CSS, especially if you’re concerned with older browser support (i.e… IE ¯\_(ツ)_/¯). I’ve found that the need for variables, conditionals, mixins, rule nesting, along with color functions and all the goodies a preprocessor comes with is much more apparent within the WordPress theming context where you wish to provide multiple color schemes for your theme or tame popular WordPress plugins to match your theme’s design and layout.
That said, I’m not here to sell you on CSS preprocessors right now, this piece is an overview on how we use Sass with Gulp in our theme and plugin development workflow, and how to incorporate the same workflow to your theme, if you so wish.
A well crafted and easy to read font is a great asset for any website. It will catch the readers eye and it won’t tire them while they consume your content. There are many plugins that can help you add fonts to your WordPress site, but perhaps you want to avoid using them and prefer to do this the old fashioned way. It’s pretty easy, let’s take a look.