Well said. I believe most programmers overlook the business utility of the product. You can have the product with the best quality code but users are not going to adopt it unless it solves their business problems. Code quality has nothing to do with the user acceptance of the product. With the entrenchment of WP in CMS space, OP is unlikely to unseat WP by rewriting the WP with the best possible code quality.

A few years ago, while searching for a development role, I was rejected by couple of people at a company with feedback that my code sample was not of good quality. Later I got the chuckle when I noticed the same people subscribed (paid) to my service that uses the provided code sample.

With respect to a software like Wordpress which is:

- huge and powerful

- vividly maintained and extended by lots of developers

- rarely features security issues which aren't fixed immediately

... the question arises whether the quality of its code base is in this case maybe rather an academic issue.

>- rarely features security issues which aren't fixed immediately

I tried to use WordPress once. I downloaded a theme from wordpress.org with the assumption that themes are reviewed before making there. Nevertheless, I did some basic pentesting before putting my app live, and I quickly found a XSS vulnerability in the search bar of the theme (their paid version featured the same vulnerability). Maybe my experience is not to be generalised to WordPress in general, but it put me off.

> Maybe my experience is not to be generalised to WordPress in general, but it put me off.

WordPress plug ins are - as far as I know - not reviewed. You're at the mercy of the respective developer.

They are, as this link seem to indicate: https://wordpress.org/plugins/add/

>Currently there are 224 plugins in the review queue, 198 of which are awaiting their initial review.

There are more than 38k plug ins available (https://en.wordpress.org/plugins/). And also from what I have seen so far - there is no extensive (if any) reviewing done regarding safety and quality.

When you first add a new plugin it is reviewed, but once it's been accepted you are free to push out whatever changes you want without review.

"users are not going to adopt it unless it solves their business problems."

Pretty much the truth of any product (software or otherwise) really.

- I do use my console on a daily basis (fish bash)

- I am a programmer (at least that's part of what I do)

- My blog is 50% about programming

Still - I don't see any reason why I would want to spend even a minute longer on the layout or some backend processes.

And I even less understand why anybody using a blog would want to or even need to use a terminal for that purpose ...

When programmers see a terminal, they tend to see it in terms of the freedom and flexibility it provides. To everyone else, it looks broken, primitive and weird.

But most modern frameworks and CMS platforms seem to take for granted that everyone moved on from FTP to git ages ago, which isn't the case.

Where precisely within the workflow of blogging do you think the kind of programmer you describe would appreciate using a terminal?

I wasn't talking about blogging specifically, but in general terms, having to use one for updating and deploying.

I could possibly imagine someone writing blog posts in markdown or plaintext and pushing them somewhere, but that would be the edgiest of edge cases, and even then a native app or web form would be more intuitive.

and that's why your suggestion of missing shell involvement is not that much of a great point in this context of Wordpress

I do all my deployments for all of my applications in a shell.

If I were actively writing a blog, it would be administered in the shell as well.

Surely the point was that the shell is unimportant for the vast majority of users, despite some HN missing its power.

Piping stdout to a new blog post, of course.