Things I’d want to see improved in WordPress core | Hacker News Reader

Things I’d want to see improved in WordPress core

masterwp.com

80 pointsmooreds61 comments

Since everyone else is posting their wish-list, here's mine.

Use a database like SQLite so I can back-up a website into a ZIP without being concerned about keeping a separate MySQL database backup in sync. (I wrote about this three years ago: https://billpg.com/dear-wordpress-please-stop-using-mysql/ )

Include TOTP one-time-password login in the core. (I hate having to deal with plug-ins.)

Full backup in the core. When triggered by cron, save a complete backup to some folder. The setup, once the DB is configured, would have a option to restore from a backup, including populating the database, themes, wp-content, etc. Skip doing a backup if nothing has changed since the last one.

Make multi-site easier. There's so many steps where I have to paste stuff into config files. Instead, have all of it ready for me to create a new site and if I never stray into that section and create a new site, no problem.

Lose the URL settings and work it out from the request. If a request (after URL rewriting) comes in looking like example.com/thing/index.php?abc=xyz, then you know what the base URL is. If I install wordpress as localhost:8080 and suddenly requests start coming in as example.com:443, I really don't want a redirect back to localhost:8080.

> Include TOTP one-time-password login in the core. (I hate having to deal with plug-ins.)

What's everyone currently using for this?

I use JetPack. That lets me sign in with my WP account, which is protected by 2FA.

Static site deployment without plugins would probably be popular too.

Not what you were asking for but btw with Cloudways their automatic backups will create a zip with the MariaDB dump included. I then rsync this to rsync.net

I've replied to another comment here asking for SQLite -

https://github.com/stokry/wp-sqlite Not official though. Submitted a few days ago (97 comments)

https://news.ycombinator.com/item?id=31396732

The biggest mess IMO is the media library. Unsustainable, chaotic, impossible to keep in order if you happen to publish more than just a few images.

It’s not a library. It’s a file dump. If you want to reuse an asset on a non-trivial site, it’s easier to reupload the file rather than to find it in a flat list of thousands of thumbnails.

Folders, please.

And the four hopeless fields to provide an image with textual metadata (alt, caption etc). It’s impossible to understand intuitively. So anti-human, lacking understanding of what users need and are capable of grasping.

Reveal the complexity gradually, please.

Same goes for the myriads of options (special love goes to the media link/image size selector with its thoughtless defaults you have to scroll down the media library modal to even reveal itself) just to insert an image into the text.

Just to name a few problems.

Folders are something that's been needed in WordPress for 10+ years and hasn't gained any traction. It's to the point where it's beyond terrible and is a large reason I don't use WP anymore.

Folders have problems too, inflexible and depend on people managing them well. If the team can’t be bothered to namespace files and fill in metadata properly, I doubt they will manage folders well either.

It’s 2022. There’s got to be something more sophisticated than folders, something content-aware that reliably finds the desired image in the library and suggests it when someone tries to upload a dupe. How do we have computer vision reliable enough to recognize people on our phones and steer a car, but we’re still relying on metadata and folders to find images in a web CMS?

But the truth is, storage is cheap so there is no compelling reason to solve this problem. If the site ends up with 27 copies of the same JPG, who cares? Oh no, we used 30MB we didn’t have to.

That does not make sense to me at all. As a single user, where is the relation between "namespace files" and "metadata" when all I want is to upload some images to a folder named foo or 2022?

I'm not saying there isn't a better solution, but other blog/cms applications could do folders without problems 15 years ago.

We have over 8000 images and growing. If you name them properly and use alt text the searching works okay. But we also don't reuse images that much (not because they are hard to find)

The thing I want to see, above all else (and it is coming, but slowly and without any kind of apparent over-arching strategy - which it badly needs) is designer / developer control.

Gutenberg gives remarkable agency to editors, which from one angle is great - lovely to be able to add a column, shift a block upwards, pad that image over to the right without any technical skills.

On the other... I don't know a web designer in the world who wants to give their editors complete control. And rightly so. Web design - good web design (and by proxy, UX) - is about constraint as much as it is about freedom. Probably more so. Knowing what not to include, and when not to include it, is the single skill that a great visual / web designer brings to the table.

So to see interfaces like Gutenberg where anyone can ...shift, adapt, grow, shrink, add to, remove... pretty much any element in the interface - is a total disaster.

Here's how "clever" it has become (and it is, technically, and in a fun sense - clever) - you can go into the edit screen of your Gutenberg website, and then you can pull up a tab to the "Block Pattern Directory" [1], hover over any block in the list, copy it, then jump back into your website and paste it. Wow.

Even if (and man, it isn't) that list of block patterns was beautifully, thoughtfully designed, what kind of awful, awful FrankenDesign is going to result from your client taking a random smattering of block patterns and pasting them into pages on their site?

As I said, there are slow steps appearing around being able to lock blocks and block patterns - but WordPress should have been much, much more thoughtful about being open, up-front and strategic with their acknowledgement of this. I know many WordPress designers who have upped and left to look at other platforms because they need client constraint, not "ultimate freedom".

[1] https://wordpress.org/patterns/

For me at least, Craft CMS answers many of the problems you describe here. I can't see WP as anything but a dumpster fire in comparison.

I remember reading through books teaching wordpress and all of them had a variation of the line to not to go trying to change or tinker too much with the inner files that make up wordpress. It kind of reminded me of how the obelisk aliens from the 2001: A space odyssey’s sequel 2010 tells humans that they can have everything in the solar system except Jupiter.

I hesitate to even post here about my software, but "web designer first" is a key idea behind the CMS I've worked on for some time now.

https://archetypewebsites.com/

A key premise is that the designer decides where things go, and the content editors really just want forms to fill out to get content where the designer says it should go. But like any system, there is full WYSIWYG editable regions as well. (where the pink blinky text will show up...)

I've not marketed Archetype widely (but I went through Startup School a few times with YC) because of the same reasons every other developer has, Archetype has warts.

"Shameless plug" We're all shilling something. Be proud of what you've made

That's kind of you, I appreciate that. I think I am going to redo some things to target the market it serves better and maybe I will post a "Show HN" here.

> I don't know a web designer in the world who wants to give their editors complete control.

I'm thinking this might be aimed squarely at scenarios where the editor, designer and admin are all the same person.

Some truth in that, for sure. I think they're clearly aiming at the Squarespace / Wix market which is probably the scenario you describe.

Yes, that market via an overhaul of WordPress.com.

> I know many WordPress designers who have upped and left to look at other platforms because they need client constraint, not "ultimate freedom".

This is a reason why some build custom themes and blocks

That's what we do. But (at least until now, it's slowly changing...) you could still take a beautifully designed theme and butcher it by doing some of the things I describe above.

That was also my initial reaction (read: disappointment) to Gutenberg. So much so, I opened an issue on GitHub, the reply was (effectively), "What's a style guide?". That wasn't a good sign.

As for progress, the fact that you still can't define color combo pallets is (to put it kindly) weird. It like the GB Core team forgot about MySpace and what happens when the design-blind have no guardrails.

Yes, it kinda getting better. But it still feels like too much trust and responsibility is put on the user and not the tool. It's like having a text input on a form for email and not doing validation because well...you trust people will get it right. Who does that in 2020+?

The last couple of years has been a reminder of how much WP .com means to Automattic. And how little other use cases (e.g., content entered via say ACF because that's all the client wants / needs) matter to them.

As developer / designer there are multiple ways to lock things down and provide a design system for content creators.

https://gutenbergtimes.com/how-to-disable-theme-features-and...

I've worked mainly on Wordpress themes and plugins for the last 7-8 years, and I've yet to see anything resembling common best practices regarding testing, CI/CD or even deployment coming from Automattic, especially regarding themes. That would be very nice to have.

Most of the issues regarding the instability and lack of security of the platform come straight from the mantra "upload the file using ftp and the edit them straight on production server" advertised by Automattic. This is not a serious answer from a platform that allegedly controls roughly 30-40% of the websites around.

What I'm afraid is that most of those choices (not moving to current development and deployment standards, doing the bare minimum in terms of upgrades to core functionalities of the platform, forcefully intertwining data, content and appearance of the website in the same SQL tables) are well intentional, and Automattic is "pulling an Internet Explorer 6", making sure that most users are locked-in on their platform by staying very away from any modern tech that could somehow make easier for developers to move to a different platform.

It's very, very complicated to move anything written on Wordpress on a different platform without losing some content along the way .

When your website is actually just a huge ball of: pictures loosely related to your content by their dynamically generated file name, textual content placed inside layout-defining shortcodes all stored together inside a single SQL query and dinamically rewritten by some inline php written in a single functions.php file, forget about moving anything to Squarespace, Ghost, Hugo or whatever without having to actually rewrite by hand all of your posts.

Oh, and also - I'd love to see some actual moderation in the Plugin marketplace. It's become incredibly common to find a plugin being acquired by another developer and being completely replaced between versions with a completely different plugin having just a very passing resemblance with the original set of features but also integrating a slew of unrelated paid "marketing" services and subscriptions. Just today I found out a "maintenance page" plugin has just morphed into a full visual builder who immediately started nagging about having a subscription for the inevitable "pro version".

Regarding the deployment and testing, this is a direction I hope to take the content on the Branch CI (https://www.branchci.com/) and WP Pusher (https://wppusher.com/) blogs in the coming months!

I would like as much as possible of the php source moved out of the webroot. e.g. to ../

All day long bots are firing queries and POSTs at any and all php files causing massive server load and security headaches.

Just include them from the core and route to them via the core, taking care of sanitation in the process preferably.

You can do this! Support article here: https://wordpress.org/support/article/giving-wordpress-its-o...

Some very neat suggestions here, thank you to the OP and everyone who has commented so far. :) We're far from perfect, but we're about to celebrate 19 years of steady iteration, and I hope to continue iterating to bring you great open source software as long as I'm physically and mentally able. — Co-founder of WordPress

Support for PostgreSQL and SQLite -- that's all I want. (For now.)

https://github.com/stokry/wp-sqlite

Not official though. Submitted a few days ago (97 comments)

https://news.ycombinator.com/item?id=31396732

Things that I would love to see in WordPress:

  * Slim the core as much as possible. 80-20 Rule applies here. A default WP setup installs 80% of unnecessary stuff for a simple blog or website; get rid of them or make them composer packages so I can install them separately upon need.
  * A wizard-like mechanism to let me choose the type of the website or app I would like to setup initially.
    - is it a blog?
    - is it a traditional website?
    - is it an ecommerce?
    - is it a landing page?
    - what database would you like to use? SQLite, PostgreSQL, MS SQL Server, MySQL / MariaDB?
    - Monolith, microservices, or hybrid?
  * Headless by default so users can choose the front-end of their choice.
  * Full-Site Editing should become optional or even a plugin like it already exists. It's the #1 reason people and developers have had enough with WP and decided to look for alternatives; I'm one of them.

Just from digging through the WordPress source, and knowing it's a frequent source of CVEs, I think it urgently needs large-scale refactoring and rewriting. If that can't be done because of how many things depend on it, is the backwards compatibility really worth the continuous stream of security problems? From one perspective it seems kind of wrong to be encouraging people to keep using a platform that is so broken at its core. When asked professionally I tell people to use WordPress.com or another reputable managed host or just avoid the product entirely.

To be honest, the majority of the CVEs are for 3rd party plugin and themes that no rewriting of core will fix.

They couldn’t be fixed by making the plug-in model more structured and restrictive?

You could, and I think it would help. It would also shift the type of themes/plugins we see, because the discipline in making compatible themes/plugins would weed out certain types of producers.

Can I hijack this thread to note that it takes nearly a year to get a response on a WooCommerce bug report?

https://github.com/woocommerce/woocommerce/issues/28589

I ended up working with a team to build a headless API e-commerce engine to replace WooCommerce. We launched about a month after they responded. Adding our second client now.

I'd like to say this was a problem but it actually helped ensure we built a scalable reliable solution so thanks I guess.

Perhaps a separate 'session' database table for... database-backed sessions vs storing stuff in wp_options? Last I looked that still seemed to be the default. For low volume scenarios perhaps it's not a big issue, but... session data isn't an 'option', so it doesn't really even make semantic sense to put it there. Why not just put all 'post' data in wp_options as well?

I only used wp once but the most surprising thing for me was that default installation used 7 SQL tables and their schema uses 3 different conventions (table.ID/table.table_id and table.foo/table.table_foo). Maybe if DB themselves enforced some kind of limits like [a-z0-9_] this would never happen.

I was a WP dev for 5-7 years before moving on to bigger and better things. It's easy to hate on the platform, for both justified and unjustified reasons.

As a writer, it's good not great. As a low code dev, it's the best because you can do 99% of what you need to do with no licensing costs. As a regular beginner dev it's a great platform to learn on. As an experienced dev it's just terrible to get anything done and too many people never graduate from it for larger build outs. Here's just a random list of hot takes I have (keep in mind I have not worked on the platform since Gutenberg got introduced, though I imagine much of the backend code hasn't changed)

- It's not an application framework, so stop treating it like one. It's good at blogging and decent for laying out web pages. If you need it to do other things, use Laravel or Grav or something

- File management is completely unmaintainable for anything more than a personal site. I've worked on some larger 2000+ page sites and it's nothing short of a nightmare.

- Post/page versioning is basic. There are plugins that do a much better job at accomplishing this, but it's time that it makes it into core. I'm talking about an actual publishing workflow with visual diffs and such.

- The backend API is atrocious. Using methods like get_post or the_content are great examples of why people hate PHP. Inconsistent naming, unclear usage, no namespacing, etc etc makes it really hard to read code. I'm a .NET dev so I'm probably a bit biased but with the amount going on under the hood, a service layer is necessary.

- Being able to rapidly prototype with themes and plugins is great and part of the dev experience, but unfortunately most projects never mature past the prototyping stage.

- The community surrounding WP is great, and Wordcamps are a great experience. I've given a couple of (admittedly bad) talks at WC Milwaukee and was surprised at the range of people that attend them.

- One of the talks I hosted was about how to use Xdebug with WP. Maybe things have changed, but I threw the talk together because _maybe_ 1% of devs I ever interacted with in the WP space asked if I had stepped through my code with a debugger. var_dump is a terrible crutch that PHP devs rely on way more than they should. I know things have improved with Docker compared to the days of Vagrant, but even at the time WP devs seemed to lag behind the rest of the industry in this regard.

- Last thing, I have terrible nightmares still about the database schema. Too many plugins/themes rely on post_meta and (whether you agree with them or not) I think WP needs a proper ORM.

Quick Edit: I will praise WP's for its plugin architecture with actions/filters. I've replicated this in our own .NET-based application and really love just being able to hook into places without dealing with nasty hierarchy structures.

I think your two points about Xdebug and PHP naming conventions aren't a fair lense on PHP as a whole. Seems that they're framed around how wordpress uses PHP (poorly) for some of the more basic abstractions.

You aren't likely to find those issues in any modern PHP Framework out the box.

That's why I'm bringing it up in the conversation of WordPress. The platform has probably the largest slice of PHP developers out there and lack of proper debugging techniques and an ancient-feeling codebase drives a lot of the negativity towards PHP. It's giving the language a bad name. Laravel is a wonderful framework and helped me bridge the gap towards .NET, as I was a self taught WordPress dev to start with.

>Using methods like get_post or the_content are great examples of why people hate PHP

The big problem with people getting into PHP via Wordpress is that Wordpress isn't, really, written in PHP. It's a WP-flavor subset of PHP, and a lot of it goes way, way back to when PHP could only be written with a hammer and chisel. It's been kept because a lot of things depend on it not changing. (I give the devs credit for not breaking a whole lot over the years.)

But compared to anything that's a bit more modern, or even writing something from scratch, it's a bit of a slog.

It's really incredible how far they e been able to maintain compatibility for sure, but there are just objectively bad parts of the platform they're keeping around for fear of backlash. There's a lot wrong with WordPress, and the editing experience shouldn't have been the first thing to tackle. I think it's bred many poor development practices.

no mention of security... good luck. i stopped using wordpress after i got hacked. good reason that static sites are the rage.

was it due to the core or a plugin?

very vanilla wordpress, it was a basic blog site. I think the only plugins I used were google analytics and some basic theme. I would keep it updated whenever I remember but maybe it wasn't often enough. Not exactly sure what the vector was and from whatever quality of analysis I did, the system didn't appear damaged beyond the changes made to the wordpress folder and luckily, the damage didn't seem to escape the www-data user that the http server ran as.

I'm gunna suggest compromised hosting. The issues I've seen (once plugins / core / php is up to date and obvious stuff sorted) has been almost entirely on shared hosts.

Oh, interesting, indeed could have been php.

Php is a beast of an attack surface. On every php install I try to do as much hardening as I can, especially with `disable_functions`, since you can make it much harder for someone to get a useful reverse shell, or other nasty things, like the built in `shell_exec` function.

https://www.madirish.net/?article=229

I'm betting most WordPress shared hosting doesn't do that, nor give people the means to set up a web app firewall in front of it. Without these things I'd never want to expose a WordPress install to the internet :)

his admin creds were probably

admin / abcd123!

Guessing passwords? You don't even have to try that hard. Have you seen the list of WordPress CVEs?

Here is one just from January of this year,

https://www.debian.org/security/2022/dsa-5039

"Several vulnerabilities were discovered in Wordpress, a web blogging tool. They allowed remote attackers to perform SQL injection, run unchecked SQL queries, bypass hardening, or perform Cross-Site Scripting (XSS) attacks."

Sure have! Mentioning the admin creds were more so tongue in cheek because there are a lot of folks who use the default 'admin' username.

Port it to a modern language so PHP can finally die, add support for PostgreSQL and MS SQL

If all you're worried about is Core: https://apps.peachpie.io/Item?id=PeachPied.WordPress.AspNetC...

> All of WordPress as a .NET Standard assembly, without PHP.

Mentions both performance and security benefits.

Some of us like PHP. I'd even go so far to say there are dozens of us... DOZENS!

I've not played with it yet but I've heard good things about the newest version of PHP, could anyone confirm?

There is a bunch of relatively new stuff in place that really help: Enums, match, readonly (classes), attributes for metadata, union types in function signatures (very useful), improved destructuring. Also some issues with traits and interfaces have been resolved since a while.

Those kind of changes are good for PHP, because they give you more tools to write compact, simple code that plays nicely with some of the legacy builtins/libraries and so on. It's remarkable how much it has been improving.

However, it's still a clunky language, because almost every feature has its weird caveats and limits that a more modern, well designed language just doesn't have.

Care to point out what bothers you in the latest versions of PHP?

not a fan of php either but I wouldn't go that far. I'd love to see it reimplemented with modern conventions over Laravel. As much as i dislike php in general, I have to admit the laravel guys have done some amazing stuff.

Absolutely love Laravel!!

Reply on news.ycombinator.com