- Contribute to projects like Calypso. With WordPress.com moving to Calypso, and the potential for self-hosted WordPress.org sites to use it, being able to understand it on a deeper level (along with the API) can help me be able to dig out bugs, submit fixes, and work towards enhancements.
- WordPress Plugins. I’ve got a couple of very niche plugins out on the main WordPress.org plugin directory. While they’re very basic, they work well for what I needed at the time, and it seems a few other folks needed them too! I would really like to work on enhancing one of them with some settings, since it enables Jetpack functionality for a theme framework that otherwise would require the user to modify their theme.
However, a number of sites are also blocking /wp-includes/. While it doesn’t seem obvious, there are a number of things that live here which would need to be accessed by users (i.e., crawlers) to render pages properly. For example, Dashicons, the small icons you generally associate with the admin side of WordPress, can often be called by themes for front-end usage. Another major thing that can hinder proper rendering by crawlers is jQuery. Sometimes, themes will enqueue a different version, but by default, it lives in the /wp-includes/ folder. If we dive even further into the issue, we’d see that the built-in emojis and comment reply handling would also be affected.
So, what can be safely blocked? At this point, here’s what a “compliant” WordPress robots.txt would look like (as far as what is safe to block). Of course, you’d want to add in your own sitemap directives and other special cases, but this is a good starting point.
Questions or comments? Leave them below!
(originally posted on Bring Your Own Design)
Inspired by a thread on Reddit, let’s look at one of the main complaints about WordPress these days: bloated installations that run slow.
One of WordPress’s greatest strengths is the fact that anyone can purchase or download a premade theme and have a “custom” website up in a short span of time. It’s also one of the things that can cause the most headache for more experienced users. Many theme developers are obsessed with cramming as much functionality into a theme as possible in order to attract the greatest number of potential users. The byproduct of that is a theme that causes the site to load slowly, causes conflicts with plugins, or is simply difficult to arrange the content the way you want.
The vast majority of users who buy layout builder themes probably don’t actually need them. With custom-built WordPress themes, just about any layout can be accommodated through the use of widget areas and custom post types; both of which are built-in functions of WordPress. The will cut down on the number of running functions in the back end of the site, and speed up how quickly the site loads and increases the number of concurrent users it can serve.
Additionally, a custom WordPress theme can be geared towards serving exactly the sort of content that the site needs. Instead of forcing your content into a pre-built theme’s layout, a custom built theme can be laid out in a way that makes sense for the information you want to communicate to your users. Using the custom post type functions, you can configure custom “things” for displaying and managing on your site. Most pre-built themes don’t use custom post types, and the ones that do use them have a lot of added overhead with functions that make them possible to configure in a theme manager.
Finally, a growing reason many companies prefer custom built WordPress themes is for search engine optimization. Although many pre-built themes have SEO functions built in, they tend to be extremely basic, or even outdated. It’s also more difficult to add functionality to premium themes in regards to things like OpenGraph code, A/B testing, or heatmap tracking. Custom built themes give you the space to choose where and how you’d add these sorts of things, and it makes it easier to troubleshoot when it’s not working properly.