I get a lot of client requests for “Store Locators” or “Location Finders”. There are some plugins like MapPress and WP Store Locator that work well for simple Location Searches, but as soon as the client has requests for specific functionality or designs, these pre-made options start to fall short, and you end up spending more time fighting their code than writing your own. read more »
For the most part, the file-structure of WordPress themes is pretty logical, however, there are aspects which keep bothering me about the Template Hierarchy:
- home.php – I understand the historic reason why the blog’s main archive is named
home.php, but every time I make a new theme, I wonder why such an illogical naming convention still persists. It’s confusing to new users, and simply serves to continue the flawed narrative that the blog is the core of the WordPress experience.
- front-page.php overrides page templates – This is particularly frustrating when a parent theme includes a front-page.php file, as there is no way to offer template file choices in the child theme, without modifying the parent.
- Custom URL routing is complicated – Sometimes I need a specific url to run my own code, outside of a traditional template file. Often, I’m stuck defining custom rewrite rules and template redirects, or jamming my code into shortcodes and custom templates.
Being a developer. I decided to fix these perceived flaws.
I am generally seen as a critical voice to WordPress’s Gutenberg editor. It is true that I feel there are many places where criticism of Gutenberg is valid, such as in timeline, scope of initial releases, and methods of post storage. However, there has been a lot of criticism of Gutenberg recently that is based on misunderstandings or miscommunication of the project goals and the definition of a “block.” To that end, I’m going to try to distill down what the “block” paradigm is all about, and why it is crucial to WordPress’s future. read more »
One of the oddest remnants of the early versions of WordPress are attachment pages. I can count on one finger the number of times I’ve thought “I’d like a dedicated page for every image on my site”. Normally, unused and illogical features like this can just be ignored. However, attachment pages aren’t just a harmless remnant of a bygone era.
Attachment pages have dedicated urls, that are based on the name of the image, and overlap with the slugs you can set for posts, pages, and custom post types. Because of this, if you upload an image named faq.jpg, you may find yourself unable to add a page at the address /faq. This can negatively impact your SEO, and is an incredibly frustrating issue to try to identify and explain to clients. Beyond the URL issue, they are another template that needs to be fully themed and branded, just in case a client runs across the page by accident. As such, they need to die. read more »