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

The complicated futility of WordPress

coderjerk.com

Post reply on HN
Print view View original

151–160 of 241 posts

Re: The complicated futility of WordPress

#151

Post by taubek »

gnz11 wrote: post #139
dgb23 wrote: post #117

Earlier quoted context omitted.

The issue is that if you’re developing like this on WP you don’t gain much from it except the ability to use a select few plugins and an admin UI. At this point why not use a solid PHP framework like Laravel?

> The issue is that if you’re developing like this on WP you don’t gain much from it except the ability to use a select few plugins and an admin UI. At this point why not use a solid PHP framework like Laravel? Agreed, if you have a dedicated engineering team, but most non-tech companies that need basic websites don't...so in that context, Wordpress's admin UI is a big gain. It's familiar to users and provides media…

I can tell you that new users like Gutenberg. It is us, the old shortcode style users, that have/had a problem with it. It took me some time to switch to it but I must say that I like it now.

Things like copy/paste from Google docs with keeping all of relevant the styles and links works. And I guess that a bunch of users is doing that - using WP as a platform for distribution of content.

Re: The complicated futility of WordPress

#152

Post by cmccomas »

amanzi wrote: post #9

I've been working with WordPress for a long time and have run a blogging network built on Wordpress since 2005-ish. Over the last few years, it's felt like I've been swimming upstream fighting against WordPress as they have tried to morph into a general website publishing tool (in order to compete with Wix, SquareSpace, etc) rather than their initial blogging roots. Security has never been a WordPress strong point an…

I feel your pain. We have a WordPress network pushing 600 sites and I'm kind of concerned about the future of WordPress and think daily about migrating over to Drupal (or even exploring CascadeCMS or something along those lines).

When we picked WordPress back in ~2012 as our CMS it was because of how simple the editing of post/page content was compared to the alternatives. The majority of our content editors are student assistants, graduate assistants, least tenured faculty member, etc. People who aren't that technical and also have a dozen other things that are their actual job, unlike updating the departmental website which just got dumped on them.

We've done a ton of work with our theme and in-house plugins to keep WordPress super simple/basic for them, overwriting and undoing a lot of what core has added over the years. Most of the site editors find Gutenberg too complicated, so we're running the Classic Editor plugin in a ton of our sites. Our content editors just want to come to a CMS, have a text box where they can add content, add heading tags, links, images, use some of our shortcodes (from custom TinyMCE buttons) to add some styled components to their page. They don't want a full-site editor, they're not remotely qualified from a UI/accessibility perspective to be messing with anything really than just the base content of the page.

Re: The complicated futility of WordPress

#153

Post by camillomiller »

jawngee wrote: post #64
ivanmontillam wrote: post #54

Earlier quoted context omitted.

My business partner and I hit a wall when we tried to automate WordPress. We tried to implement a plugin where Events in WordPress would be triggered, evaluate Conditions and then execute Actions (Send email, Trigger Webhook at Zapier, Update fields over the triggered record, etc.) Turns out, WordPress is not architecturally ready for this much evolution. And that's when we got disenchanted from WordPress and went to…

This doesn't make any sense or you are explaining it badly. You are basically describing how every WordPress plugin already works via filters and actions (collectively referred to as hooks).

Oh it makes a lot of sense! What OP is describing is the experienced programmer approach to Wordpress. Should I check what's already in place for event handling? Absolutely not, I should put my very opinionated layer on top instead of understanding how the system works and go with it. I had major arguments with developers in my team in the past about this, as they would completely miss the point (let's ship) spending time instead reinventing the wheel all the time. They would also be extremely annoyed when I would easily point to the documentation page about how wordpress does exactly what they tried to re-write forcing the system's philosophy.

Re: The complicated futility of WordPress

#154

Post by globalise83 »

taubek wrote: post #120
dgb23 wrote: post #117

Earlier quoted context omitted.

The issue is that if you’re developing like this on WP you don’t gain much from it except the ability to use a select few plugins and an admin UI. At this point why not use a solid PHP framework like Laravel?

I was on the other side of the table, I was working for a company that was developing WP plugins bunt I'm not a developer. During my years there I've meet a lot of developers. I've seen different approaches. The most surprising thing to me was headless WP. I didn't get why do they even want WP. Take a look at WooCommerce. I guess that it is much easier to do some of the custom code than to reinvent a wheel. Not to me…

Headless WooCommerce is actually pretty cool - you get free admin UI for managing the shop, and can build whatever frontend you like without the constraints of WordPress. Seems like a no-brainer for anyone who can do a bit of frontend development.

Re: The complicated futility of WordPress

#155

Post by camillomiller »

pupppet wrote: post #85

I’ve easily built hundreds of WP sites and Gutenberg makes me sad. Anyone raving about the block editor has clearly never used one of WP’s paid page builder plugins like Beaver Builder and Elementor, they’re in a whole different league. You of course can continue using these plugins, but the absolute chasm in quality separating these plugins and Gutenberg highlights Automattic doesn’t have the technical or design kno…

LOL you just mentioned the worst thing that could happen to wordpress for client-side work. These plugins are a hot mess of unneeded feature. The amount of code and conditions they create to do something you could solve in a line or two of CSS is appalling. The markup they output is some of the worst, bloated, unreadable markup I've ever read.

Re: The complicated futility of WordPress

#156

Post by sneek_ »

prog5 wrote: post #56
imilk wrote: post #50

Earlier quoted context omitted.

Directus is an amazing open source tool that you can self host as easy as deploying a Node app. You can setup content types with a nice UI, very configurable roles so a client can't break the site, a media library that can hook into S3/DO Spaces, a REST or Graphql API built in, webhooks, revisions, works with many different DBs, and a bit more I'm not thinking of. I'm not affiliated with them at all. Was just very pl…

This looks amazing thank you. I'm curious about the REST API part. Have you used that before? How configureable is it? It sounds like a scaffold of some sort... but, what if I needed to do some custom data processing on the data before returning it in the API, are there hooks for that?

Hey prog5, you should check out Payload CMS if you need that type of flexibility and extensibility. Payload has Hooks that allow you to do exactly what you're saying.

Re: The complicated futility of WordPress

#157

Post by sneek_ »

seanwilson wrote: post #29
chyeah wrote: post #26

Earlier quoted context omitted.

Prismic's "slices" might be what you're looking for if you want out-of-the-box functionality and hosting. If you're wanting a bit more flexibility from a code-perspective (and you don't mind TypeScript), I've found Payload CMS to be a great option to build out a page builder as you've described using their "blocks".

Looks like Prismic and Payload CMS aren't open source? https://github.com/payloadcms/payload/blob/master/license.md - "Payload is free to download and install—and free to use for Personal Purposes. We are passionate about Payload, and we hope that you will enjoy it, too. A valid license is required to utilize Payload as detailed below" https://prismic.io/faq/product - "Proprietary, not open source"

Ahhh thanks for the shout out to Payload! I'm one of the founders. seanwilson, Payload is technically open source and completely free forever for up to one admin panel user. There are no restrictions at all besides that and the code is fully open on GitHub.

Would this model work for you, or would you like to see changes to our current model?

Re: The complicated futility of WordPress

#158

Post by pupppet »

bdlowery wrote: post #110
pupppet wrote: post #85

I’ve easily built hundreds of WP sites and Gutenberg makes me sad. Anyone raving about the block editor has clearly never used one of WP’s paid page builder plugins like Beaver Builder and Elementor, they’re in a whole different league. You of course can continue using these plugins, but the absolute chasm in quality separating these plugins and Gutenberg highlights Automattic doesn’t have the technical or design kno…

Why use elementor when you can get far better Google Core Web Vitals, and actually write semantic html all with ACF? Writing PHP isn’t that hard!

A drag and drop page builder can churn out a page in a fraction of the time and many plugins generate fairly decent HTML, it’s rarely worth coding from scratch any more.

Re: The complicated futility of WordPress

#160

Post by paulryanrogers »

pwdisswordfish9 wrote: post #112
schroeding wrote: post #101

Earlier quoted context omitted.

Honest question, how would that work? PHP code is not sandboxable (ignoring the ability to disable functions), AFAIK. Is it? So plugins do have complete (read) access over the entire code, the secrets in the config files, the database etc.? Not allowing plugins to directly execute PHP code would either fundamentally break the wordpress plugin model or require an interpreter for a turing-complete "wordpress plugin pro…

Maybe run it on Peachpie (which should already give perf gains) and go with the new plugin model.

WP doesn't control where folks host it. Limiting its support to one .Net implementation would severely limit its market.
Post reply on HN