WordPress the Good

As a web developer you can't avoid WordPress even if you try.

I knew all the good things of WordPress, but the bad and mostly annoying things just weighted more. And especially years ago with those awful page builders that weight like a ton of bricks.

Things changed with Gutenberg block builder and I started to use WordPress for simple low budget websites. Still trying to avoid WordPress.

The other day I caved and reached out to WordPress for a personal project that I didn't want to put too much development time in.

I, somewhat achieved my goal. I was able to focus on the content instead of designing a website from scratch and fiddle with CSS or an esoteric CMS I have to extend myself.

These were the steps:

1. Template and Blocks

Stock WordPress with their Twenty something themes and standard Gutenberg blocks is fine, but at some point limiting. I've chosen the Neve Theme before but this time I used Kadence Themes and Kadence Blocks because they were a little bit smoother to work with.

Designing the appearance of the website takes a while because the options are overwhelming, but over the course of creating the content it's quick to adjust to the final form of the website.

The flexibility is missing if I program everything myself. I can be more focused and free, but if I don't have a design concept, I'm getting lost. WordPress themes offer some guidance in that regard on the other side, they are restrictive, which is sometimes annoying, but that's the trade-off.

2. The Menu, Structure, and Breadcrumbs.

WordPress concept for creating menus is weird, not outlandish, but confusing sometimes.

It has to be setup somewhat manually, I can mix page links, with links to categories or manual links. What I found annoying was, that these menus don't represent the Breadcrumb menu structure.

So in my case I wanted a category of the blog, being a subpage to a page with a certain topic:

I'm mixing here Page types and Post types – the two native WordPress types of pages. Posts are blog posts, pages are just pages. They are similar, but not the same.

- Home
- My Topics
    - Topic 1
        - Page 1
        - Page 2
        - Posts of Category X
            - Post X - 1
    - Topic 2
        - Page 1
        - Page 2
        - Posts of Category Y
- Blog
    - All categories and posts
- Contact

So if I call Post X - 1 I expect it do be represented in My Topics/Topic 1/Posts of Category X/ but the breadcrumb shows Blog/Posts of Category X/ - huge bummer, but since the menu is independent from my child/parent page structure and this is independent of posting types, there was no way.

I ended up writing a function that manipulates the breadcrumbs. Since I got myself into installing the Yoast Bloatware, I followed their lead in how to manipulate breadcrumbs.

It got me somewhere.

3. Custom Data or Posting Types

I needed to extend the native WordPress posts with a few additional fields, for geolocations and other data.

If you know WordPress' data storage, just about everything ands up in the wp_posts and all additional information in a wp_posts_meta table it's an incredible flexible way to store everything, and it's incredibly unoptimized and one of the reasons why WordPress can become so slow.

For my location specific datasets (a kind of posts) I created a new post type and that's really easy to do with the Pods Framework. That allows me to Grow Beyond Posts & Pages - Content Types and Custom Fields. And growing my database did do.

Initially it's really easy to create my own post type and see the result in the frontend, but when it comes to templates and archive pages, it needs a bit reading and youtube watching. The docs are not the best and sometimes outdated.

Since new post types are descendants of blog posts they behave as such, and so I ran in the breadcrumb issue there as well. But with some PHP in the function.php I was able to wire everything up as I want it.

The downside of that is, I had to hard-code IDs and stuff into that function file. But I did that in other CMS as well. That's just sometimes the part where I have to get my hands dirty.

Initially, my geolocation database is external, and I pulled the data in and rendered with a [shortcut], but I caved and went WordPress all the way and chose the custom post type route. After all the experience is not too bad, beside the redundant dataset that I created.

An interesting observation was the image field in Pods. I wanted to attach one or more image to each post/pod and that's pretty easy, but for the output I could loop through all images myself and set up a customized gallery adapted to my theme - which would be too much work, or use the internal WordPress Gallery script.

The latter one was ok, but didn't look good and had a weird behavior regarding captions.

It took an unexpected nicer turn, when I installed Jetpack it made the gallery much nicer looking without doing anything.

4. Jetpack

In the past, I turned Jetpack on for Markdown support and hated all the crap that came with it, like a WordPress Account and other stuff. After years, I tried it again, and the upselling and privacy policy implications are big. But since this was a personal project, I don't need to tell about the data collection by third-parties (in this case Automattic/WordPress Jetpack) and I wanted to see what the benefits are. And the free stuff doesn't disappoint!

I can make use of their CDN for images and compressed assets like css and js. I can use their minimal stats – to know that 3 people visited my page is enough. Since I need comments, I can use their spam and hacking protection. That will be interesting, once the spambots show up.

All in all, this was not too bad, and I enjoyed focusing on the content this time and not on building something.

This is the page if someone is interested in: https://americananana.com