Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WordPlate: WordPress on Composer with sensible defaults

github.com

Post reply on HN
Print view View original

21–30 of 105 posts

Re: WordPlate: WordPress on Composer with sensible defaults

#21

Post by tehbeard »

minusf wrote: post #17
noeltock wrote: post #5

Earlier quoted context omitted.

I think you answered your own question, the familiarity for users (seo & content) which is "end-to-end no-code" is massive (especially once extended with user-facing plugins). And you're not even speaking about making the move to Gutenberg yet. Just too much value there.

what familiarity? every single plugin's dashboard/admin page looks completely different.

Somewhat of a facetious argument, like saying the posts and site settings pages look completely different.

It's not to say there aren't some that say sod it and have their own UI library. But quite a few leverage wordpress admin styles and conventions (such as the wp_list_table).

But the quality is all over the place, much like with composer packages.

Re: WordPlate: WordPress on Composer with sensible defaults

#22

Post by cynicalsecurity »

9dev wrote: post #6

Just reading this again gives me a backflash of the horrors of working with WordPress. If you haven’t seen the source, you don’t know just how god-awful the code is - and it just won’t die, because of all the ecosystem traction it has. Even the PHP developers have chosen to ignore WordPress in language evolution considerations, as the WordPress community refuses to do accept kind of progress for their project - they…

That's a cheap, emotional and factually incorrect statement.

Thank you, I'll happily keep working with WordPress.

Re: WordPlate: WordPress on Composer with sensible defaults

#23

Post by dageshi »

pibechorro wrote: post #18
dageshi wrote: post #11

Earlier quoted context omitted.

There's no clear cut alternative CMS to use, that's the issue. If you own a wordpress site for your business and you want to change your dev or agency then you will have no problems finding people who understand WP and can work on/fix your site. It might cost you but you'll have no issues finding people to work on it. Use anything else and you'll be hunting down people who can and want to work on it. The other major…

Except they dont. Leveraging 30 plugins makes the sites a constant hack target and perform piss poor in SEO page speed test, etc. That lets fix it with plugins attitude works for entry level sites, but if you actually are profitable and competitive its more trouble than hiring someone to build a lean site, even if using WordPress for content in the backend. Less is more.

By the time you've reached 30 plugins of actual required functionality that effects page speed and existing caching solutions can't help you then yeah you probably need to build it custom, but there's a big old gulf of time before you reach that point where WP will serve just fine.

Re: WordPlate: WordPress on Composer with sensible defaults

#24

Post by kijin »

DoctorOW wrote: post #15
kijin wrote: post #9

Earlier quoted context omitted.

There's much more to WordPress than the ecosystem. If we just think of it as a legacy tool that is only limping along because of the plugins, we will forever be perplexed that it continues to exist. WordPress is the FLOSS alternative to Wix et al. It is the only practical software that enables people to create and self-host an online presence without having to type a single line of code, and without being beholden to…

> Understand the users, on the other hand, build a good alternative, and that billion-dollar market might become yours. Isn't that the entire point of Ghost?

The installation guide for self-hosted Ghost assumes that you have at least a virtual private server, and gives you a bunch of commands to type into a root shell. By that time, you've already lost 90% of the people who would have chosen WordPress.

Re: WordPlate: WordPress on Composer with sensible defaults

#25

Post by luckylion »

9dev wrote: post #19
mpol wrote: post #8

Earlier quoted context omitted.

WordPress uses the PHP-mysqli extension. The PHP-mysql extension is unused since WordPress 3.9, quite some years ago. You might mean PHP-pdo is advised. Can you explain why it is better in this regard? Also $wpdb->prepare() uses parametrised values. Not everywhere in WordPress core is it being used. Most plugins use it for direct queries (not that common), but I don't know if the plugin team refuses plugins when they…

Read this article for a primer on why PDO is a vastly better choice: https://phpdelusions.net/pdo#why And the fact that it’s 2023 and we’re somehow ok with the biggest web application there is not using parametrised queries in its core completely stumps me. Time and time again, SQL injection attacks in Wordpress or it’s plugins pop up. PDO with parametrised queries simply eliminates this issue.

> PDO with parametrised queries simply eliminates this issue.

True, but plugin authors not caring about using them is the primary issue, and that doesn't change just because wpdb uses a different API under the hood.

Re: WordPlate: WordPress on Composer with sensible defaults

#26

Post by beezlewax »

DoctorOW wrote: post #15
kijin wrote: post #9

Earlier quoted context omitted.

There's much more to WordPress than the ecosystem. If we just think of it as a legacy tool that is only limping along because of the plugins, we will forever be perplexed that it continues to exist. WordPress is the FLOSS alternative to Wix et al. It is the only practical software that enables people to create and self-host an online presence without having to type a single line of code, and without being beholden to…

> Understand the users, on the other hand, build a good alternative, and that billion-dollar market might become yours. Isn't that the entire point of Ghost?

Its written in node js though right? You can run php and mysql almost anywhere you want. Even the most basic hosting setups are pre configured for this. Apache is preinstalled on most cheap shared hosting.

That's the thing.. if you want to take down wordpress it should be something current wordpress users can easily install on their current hosting with zero extra config to do. No terminals no server settings to deal with.

A wordpress install is literally drag and drop the files onto the server with ftp and open the web address. Enter some details for the mysql dB via a ui and that's it.

After that there are thousands of themes and plugins that let you do anything from ecommerce to a drag and drop blog without much effort.

Re: WordPlate: WordPress on Composer with sensible defaults

#27

Post by jeroenhd »

eisa01 wrote: post #12

Wow, Wordpress still use MD5 hashes for passwords? That's really taking backward compatibility with old PHP versions too far! https://github.com/roots/wp-password-bcrypt#readme https://core.trac.wordpress.org/ticket/21022

Assuming you use unique passwords for your services, I think the crackability of a password isn't too big of a risk. You need to find a password dump somewhere for a specific website. I'd wager that most WordPress instances have only a few (if more than one) users in their database, you won't easily find a WordPress dump with a million passwords in it.

With an admin password you can probably upload some executable code, but if you can find a database dump online I doubt you'll have too much effort exploiting a WordPress plugin anyway.

Re: WordPlate: WordPress on Composer with sensible defaults

#28

Post by tyingq »

mpol wrote: post #8
9dev wrote: post #6

Just reading this again gives me a backflash of the horrors of working with WordPress. If you haven’t seen the source, you don’t know just how god-awful the code is - and it just won’t die, because of all the ecosystem traction it has. Even the PHP developers have chosen to ignore WordPress in language evolution considerations, as the WordPress community refuses to do accept kind of progress for their project - they…

WordPress uses the PHP-mysqli extension. The PHP-mysql extension is unused since WordPress 3.9, quite some years ago. You might mean PHP-pdo is advised. Can you explain why it is better in this regard? Also $wpdb->prepare() uses parametrised values. Not everywhere in WordPress core is it being used. Most plugins use it for direct queries (not that common), but I don't know if the plugin team refuses plugins when they…

>Also $wpdb->prepare() uses parametrised values.

They appear to be a hand-rolled PHP version of imitation client-side parameterized values, not the actual database library ones.

https://github.com/WordPress/WordPress/blob/master/wp-includ...

Re: WordPlate: WordPress on Composer with sensible defaults

#29

Post by 9dev »

cynicalsecurity wrote: post #22
9dev wrote: post #6

Just reading this again gives me a backflash of the horrors of working with WordPress. If you haven’t seen the source, you don’t know just how god-awful the code is - and it just won’t die, because of all the ecosystem traction it has. Even the PHP developers have chosen to ignore WordPress in language evolution considerations, as the WordPress community refuses to do accept kind of progress for their project - they…

That's a cheap, emotional and factually incorrect statement. Thank you, I'll happily keep working with WordPress.

No, it’s not. My statement is grounded in years of working professionally with CMS systems for customers at an agency, as an engineer helping out our marketing department, and maintainer of a popular niche CMS.

If you’re happy with Wordpress, by all means, keep on going. My critique isn’t targeting you.

Re: WordPlate: WordPress on Composer with sensible defaults

#30

Post by 9dev »

luckylion wrote: post #25
9dev wrote: post #19

Earlier quoted context omitted.

Read this article for a primer on why PDO is a vastly better choice: https://phpdelusions.net/pdo#why And the fact that it’s 2023 and we’re somehow ok with the biggest web application there is not using parametrised queries in its core completely stumps me. Time and time again, SQL injection attacks in Wordpress or it’s plugins pop up. PDO with parametrised queries simply eliminates this issue.

> PDO with parametrised queries simply eliminates this issue. True, but plugin authors not caring about using them is the primary issue, and that doesn't change just because wpdb uses a different API under the hood.

No, but nobody will encourage them to. Wordpress has fostered an ecosystem of bad practices that is mostly resistant to change.
Post reply on HN