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

201–210 of 241 posts

Re: The complicated futility of WordPress

#201

Post by ceroxylon »

KronisLV wrote: post #178
taubek wrote: post #77

Earlier quoted context omitted.

I love WordPress. It is kind of a universal tool: you can make simple web sites, you can use it to build complex systems. It is always better if you have developers that know what they are doing. WP development is not installing dozens od plugins to achieve some effect on your web. I guess that WP wants to become "one to rule them all". This means that they strive for even bigger adoption rate among users. FSE is the…

> It is kind of a universal tool: you can make simple web sites, you can use it to build complex systems. It is always better if you have developers that know what they are doing. Here's a question: suppose that you want to use WordPress as a starting point for a CRUD app with some basic permission controls, the ability to dynamically add content and maybe even write your own search logic which respects those permiss…

Usually the designer route in WP is to watch a tutorial that shows you worthwhile plugins and how to use them effectively. Things like Elementor, TablePress and WordFence changed my life and made plenty of clients happy, while my developer knowledge was still (and still is, really) in its infancy.

Re: The complicated futility of WordPress

#202

Post by benfrain »

Hoefner wrote: post #183
benfrain wrote: post #175

My blog has been on Wordpress since about 2007. It works, and I appreciate that it’s free but I’ve always hated working with it. If someone made a node based equivalent (so I can at least use a modern templating language) that supported comments I would be all over it. The commenting system is the only real reason I stay. There’s nothing else I can find that doesn’t necessitate stitching multiple services together ju…

Try https://ghost.org/ ( https://github.com/TryGhost/Ghost )

No commenting!

Re: The complicated futility of WordPress

#203

Post by yurishimo »

samtho wrote: post #189
donohoe wrote: post #179

I've too have been working with WordPress a long time. I built Quartz (qz.com) and The New Yorker (newyokrer.com) and other sites on WP. However so much of what this author says resonates more than I care to admit. I have a good relationship with WP but I worry about the future.

I’m actually surprised that there is not a popular news-oriented CMS (that I’m aware of). WP has survived so long despite the abysmal architecture and myriad of security issues because it’s just so damn flexible. It really has somehow both transcended blogging while being so stuck in it. I suppose it’s ubiquity, especially during the earlier days of corporate internet, allowed all walks of life to start a website wit…

You mention the security stuff, but for any site running at scale, it's not really an issue. They don't use a billion plugins and they usually run on infrastructure designed from the ground up to run WP. Heck, A8C's hosting platform (WP VIP) won't let you deploy code that doesn't pass a host of linting rules.

I'm working on a site right now for a big company that's moving to VIP. We have 7 plugins, 2 of which are from VIP, and then 4 that the company I work for wrote and now maintains for use across all of our clients. Everything else is custom. The theme is 100% custom.

When orgs choose WP, they do it because they want the interface to reduce training costs, and the platform to reduce dev costs because they can take that codebase to dozens of different consultancy agencies and have them pick up where the last people left off.

Re: The complicated futility of WordPress

#204

Post by imilk »

vgb2k18 wrote: post #146
seanwilson wrote: post #21

Are there any good options for an open source headless CMS that works with a static site generator that has a page builder that has quick and accurate live previews before you deploy? E.g. so you can build new landing pages from header, testimonial and contact form blocks. There's lots of options if you just want Markdown but this isn't enough for heavily branded business websites where you need to check how complex…

Wagtail - https://wagtail.io/

Never heard of this before, but it does look very useful.

Re: The complicated futility of WordPress

#205

Post by senko »

0xbadcafebee wrote: post #185
senko wrote: post #163

Earlier quoted context omitted.

I was there. It was horrible. FrontPage output was an unholy mess and god help you if you ever needed to dive in that codebase by hand. Current solutions are far from perfect but I never want to go back to that.

Do you ever dive into a PowerPoint file by hand?

No.

Do you ever publish your web content as PPT? Written a web app using PPTX?

Re: The complicated futility of WordPress

#206

Post by withinboredom »

schroeding wrote: post #101
TimTheTinker wrote: post #20

Earlier quoted context omitted.

Third-party plugins are subject to WordPress's security model and implementation. Automattic could create a PluginV2 system with tightened security and new requirements for plugin developers, then put a plan in place to deprecate and remove support for v1.

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…

You can sandbox php by changing the context the thread is running in before entering the plugin code. The issue is that there’s (currently) no delineation between internal code and plugin code (actions / filters) and changing back out of that context without a plugin doing the same to escape the sandbox.

Re: The complicated futility of WordPress

#207

Post by taubek »

IncRnd wrote: post #174
taubek wrote: post #151

Earlier quoted context omitted.

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.

It's not just shortcode using admins who don't want to use Gutenberg. There are many people who have used any one of various visual composers for years. They generally don't have the time or inclination to learn a new workflow that doesn't support what they already do. Having a classic editor plugin has nothing to do with characterizing people as crufty throwbacks who can't learn new things. Many people are in the bu…

Yes, I get it. I've used Elementor, DIVI, Beaver Builder, WPBakery , ... And I always hated when I had to switch to a new builder for some new project.

Re: The complicated futility of WordPress

#208

Post by TimTheTinker »

schroeding wrote: post #101
TimTheTinker wrote: post #20

Earlier quoted context omitted.

Third-party plugins are subject to WordPress's security model and implementation. Automattic could create a PluginV2 system with tightened security and new requirements for plugin developers, then put a plan in place to deprecate and remove support for v1.

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…

> PHP code is not sandboxable

People said the same about JavaScript, and yet smart people figured out ways to do it. For example: https://github.com/googlearchive/caja

PHP may be particularly challenging to sandbox, but it's not too much for talented engineers to figure out.

As a near-last resort, a secure PHP subset language could be developed.

Re: The complicated futility of WordPress

#209

Post by jefurii »

sdze wrote: post #83
raylus wrote: post #72

Django [ https://www.djangoproject.com/ ] + Wagtail CMS [ https://wagtail.org/ ] have been great alternatives for our team.

Why did you choose this over WP? Or was WP not even considered as a candidate? I mean the ecosystem of WP seems to be a magnitude greater.

Django developer here. I have limited experience with WP but used Drupal back in the day, and from everything I've heard WP is the same with respect to what I'm going to say.

You can touch your nose two ways right? You can just reach up, or you can contort your arm and reach around your head. Working with Drupal very much felt like the latter.

I had to jump through so many hoops to do everything. Just one example: If I wanted to turn off a Preview button in one part of the site, the code in that view had to check what application was running, or ALL the preview buttons in the whole site would disappear (i.e. there was no app scope). Drupal databases were hairy balls of complication, but that's the case with every system I've looked at that has to support "every" use-case.

With Django you just build what you need and you're done. It's very straightforward. Your code and your data model can stay really simple. I built out whole sites really fast with it, even when I was a relatively inexperienced developer.

It's not about the size of the ecosystem, because with a tool like Django it's really simple to just build what you need yourself.

That said, this model works best if you have access to at least one developer. If you're not willing to cough up for that, you're at the mercy of things like WordPress.

Re: The complicated futility of WordPress

#210

Post by deltarholamda »

yurishimo wrote: post #190
deltarholamda wrote: post #177

Earlier quoted context omitted.

I can answer this: because people do not want to pay for a developer, they want to pay for a designer. (It is exceedingly rare to find both in a single person.) The designer can, within the structure and strictures of Wordpress, build a site with all the whizzy things the client wants, and they can charge $X for it. A developer can do all of that as well, but they will probably need a designer as well (see above pare…

I was with you until the end there. Tools for performance monitoring exist. Query Monitor is a great starting place for a free plugin. Lighthouse will tell you if you have a million blocking requests. New Relic is offered by any web host worth a damn and WP plays very nicely with it.

Fair enough, but you just listed three different tools, and you may have to go through all of them to find what's going on, and come out the other end just as lost.

I mean, I get it. I've written some stuff that screws the pooch performance-wise, and the solution isn't immediately clear. But with WP, and with enough installed plug-ins, the reason for the slowness may simply be "in order to work with WP, there is a lot of back-and-forth with the DB amongst all these plug-ins," and there ultimately isn't anything you can do about it.

WP is amazing that it does so much and works as well as it does, but let's not pretend it's not a bit of a faff sometimes.

Post reply on HN