Live data from Hacker News

On not choosing WordPress for the W3C redesign project

w3c.studio24.net

131–140 of 208 posts

Re: On not choosing WordPress for the W3C redesign project

#131
post #10

Earlier quoted context omitted.

such as?

https://craftcms.com/docs/3.x/matrix-fields.html Get a few hundred of those on a site and see how much ram you need.

Can validate. Craft is amazing, by far my favorite CMS, but if you have a true enterprise site and need to do any changes to fields, it's a nightmare. Crashes the site constantly, only solution is to boost RAM.

Re: On not choosing WordPress for the W3C redesign project

#132

Glad they realized the issues of Wordpress but a shame they went with proprietary nonsense with a faux license. A php based platform has a lot of negatives for scalability. Using a cms to generate static content is much more simple, scalable and cheaper. Keep it simple.

Unless there's dynamic content, the pages are going to be cached anyway. I'm not sure static would buy anything much really. So few would be hitting the actual site.

Having 100% bulletproof site is huge (e.g. you can host static site on s3+cloudfront) vs worrying to be not-hacked, not-overloaded etc

Re: On not choosing WordPress for the W3C redesign project

#133

When working with WordPress, can anyone recommend a trustworthy place to go for plugin recommendations? The problems I find with WordPress are: - WordPress core is missing a ton of stuff you'd expect to be there so you have to turn to plugins. - It's hard to assess the quality of plugins. They conflict with each other, kill page speed, they break as WordPress is upgraded, and there's tons of bad advice you have to na…

> You can get pretty far with just ACF, a contact form plugin, an optimisation plugin (how is page caching still not built into WordPress?), and coding small features into themes directly. This. I work on large, high-traffic WP sites a lot, and we're essentially keeping a hand full of plugins and writing everything else ourselves. Lots of plugins are complicated because they want to enable ordinary users to customize…

Can you recommend any plugins in particular or a place you'd trust for plugin recommendations?

> Lots of plugins are complicated because they want to enable ordinary users to customize their behavior, which you don't need if you have even basic php skills

Yes, I've realised this too. Generally you pay for the features + customisability you don't use as well.

E.g. if you want to add social sharing icons yourself, just inline a few SVG icons with links to like 3 social networks into your theme and you're done. A social sharing plugin though will offer to connect to 100+ social network, with live share counts, icon choices, colour choices, page placement choices etc.

On top of this, most plugins aren't optimised and they'll load JS and CSS you're not even using (including on pages you're not using the plugins at all).

Similarly, I've seen contact form plugins that for a simple three field contact form will load underscore JS, backbone JS, fontawesome, jQuery and a pile of CSS.

I think part of the problem is WordPress plugins compete with each on features and need even more features on top to charge for the premium version, so page speed and robustness via simplicity get lost in the noise.

Re: On not choosing WordPress for the W3C redesign project

#134

Does anyone know why Drupal wasn’t considered?

> Drupal also has this complexity issue which makes developing sites harder than it needs to be, and is why we didn’t consider that platform either. I’ve talked to other agencies who have decided to drop Drupal due to its complexity.

I am sure I’m biased as I’ve spent a lot of time in Drupal. There are certainly some oddities wrt Drupal’s frontend but dismissing it entirely on that seems silly. Especially when it does a decent job of ticking some of their other boxes (e.g accessibility, open source, headless tooling).

Re: On not choosing WordPress for the W3C redesign project

#135
Massive props to Studio 24 for showing their working in public on all of this. It is amazing to see. More large scale projects of this kind should do this sort of thing.

Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!

There are a couple of interesting things in this article.

1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.

2.

> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.

It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?

Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.

3.

> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.

This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.

- Use Craft

- "We are currently considering a Headless CMS option for front-end page delivery"

It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".

Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.

Further: the headless CMS option.

Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.

One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?

Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.

Re: On not choosing WordPress for the W3C redesign project

#136
post #114

Is there an open source CMS that people would recommended for use with a static website generator for large websites? Netlify CMS is interesting for example and I love how content changes are versioned in Git. I like static website generation but don't want to get locked into a proprietary CMS platform.

You can use Wordpress as a headless CMS. > and I love how content changes are versioned in Git Developers love themselves some Git, but that's probably not the best content workflow tool for people who will write copy which actually accomplishes the goals of the site (like making sales.) Why do developers in this thread act as if it's going to be developers writing the content?

> Developers love themselves some Git, but that's probably not the best content workflow tool for people who will write copy which actually accomplishes the goals of the site (like making sales.) Why do developers in this thread act as if it's going to be developers writing the content?

I never said to expose sales people to Git. Have you tried Netlify CMS? All it's doing is giving non-technical users a pretty frontend to edit posts/pages that are stored as Markdown files on GitHub, so it's user-friendly + developer friendly. Check out the video: https://www.netlifycms.org/

Migrating static sites where the content + theme are all stored in Git is a dream compared to WordPress. A lot of WordPress sites aren't even under source control (with automatic security updates live updating the CMS code with no diffs if something goes wrong or it gets hacked), and because some state is stored in the database and other state stored is in the file system, it makes migrations, upgrades and rollbacks overly complicated.

You could use WordPress as a headless CMS, but you've still got to have a plan for how you're going to backups, rollbacks and deploys for content + custom editor features.

Re: On not choosing WordPress for the W3C redesign project

#137
post #122
post #115

Earlier quoted context omitted.

> A php based platform has a lot of negatives for scalability This is an outdated view of how websites are developed today. > Using a cms to generate static content is much more simple, scalable and cheaper. If the market agreed with you, then this would be the dominant method for creating websites today. You aren't smarter than the market. Maybe you aren't looking at the right variables which go into your calculatio…

Static generation is common approach, and has gained a lot of popularity in recent years.

Sure, I said dominant, not common.

I don't know how representative these results are, but it's a clue.

https://trends.builtwith.com/cms/WordPress

I don't now if there are numbers for static sites on there, but my guess is that those numbers don't come close to Wordpress, especially for the top million sites.

Re: On not choosing WordPress for the W3C redesign project

#138

Earlier quoted context omitted.

Most of this plain isn't true - afraid it does feel very much like a bubble there! > - Uses PHP 5 spaghetti code with a handful of garbage event listeners and output buffering I mean it has listeners for almost every event you might want to interupt and trigger something on that are well documented and have been for decades. The PHP 5 code is very much legacy so I will grant you this. > - Has no integration with comp…

> Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years. You need to use a third party service or setup. > Yes, but adding further content types at the level of code or these plugins is easy, trivially so. Compared to what? Drupal? CraftCMS? Joomla? Where you go to a UI and do it all, versus installing a plugin with it's own qu…

Fair enough. Probably at "agree to disagree" here.

I'll agree that its easier to do custom post types on other CMS. But sometimes at the cost of real overheads in terms of complexity for users to swallow to get there.

Caching is built into the core, which is what all caching plugins leverage, the interface to it is hidden.

PHP is a theming engine.

I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. It has an alternative syntax to make this easier. It's one of the unique capabilities the language has over almost all other languages you'd use on the web. More often than not you end up escaping into pure PHP in any case in something like Blade.

> But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.

Don't think its garbage for the reasons explained, but I think this true of all software projects. Seen plennty of Drupal, Laravel or Joomla projects end in this state.

Re: On not choosing WordPress for the W3C redesign project

#139

Earlier quoted context omitted.

Does Gatsby build fast enough for a large site though? I find their business model strange if I'm understanding it correctly - faster builds are a paid feature. I also don't understand the hype. I think it's just good marketing, people don't know the alternatives, and it uses React. I usually side with Hugo because it's so fast and simple to get running. I don't love the template language but the majority of sites do…

Not sure. My impression is Gatsby is solid but still growing, the tech still evolving. So today might not be the same answer next month.

This sounds like the hype I mentioned earlier if I'm honest. I'd rather just use Hugo today and know most small sites I make are going to build in less than a second without having to pay extra.

Re: On not choosing WordPress for the W3C redesign project

#140

Earlier quoted context omitted.

> You can get pretty far with just ACF, a contact form plugin, an optimisation plugin (how is page caching still not built into WordPress?), and coding small features into themes directly. This. I work on large, high-traffic WP sites a lot, and we're essentially keeping a hand full of plugins and writing everything else ourselves. Lots of plugins are complicated because they want to enable ordinary users to customize…

Can you recommend any plugins in particular or a place you'd trust for plugin recommendations? > Lots of plugins are complicated because they want to enable ordinary users to customize their behavior, which you don't need if you have even basic php skills Yes, I've realised this too. Generally you pay for the features + customisability you don't use as well. E.g. if you want to add social sharing icons yourself, just…

I can't recommend anything beyond ACF (and that I'm somewhat hesitant, it has a few annoyances) and maybe Autoptimize (feels stable, but haven't worked with a lot). I work with Yoast a lot because clients like it and editors know it, but I wouldn't recommend it. I hate all Permalink-Plugins I've ever seen. I don't do any caching in WP, I use varnish.

Otherwise I experienced exactly what you mentioned. Install a plugin, write code to dequeue its resources from all pages it's not running on. Of course, there are plugins that help you do that, but it's yet another plugin!

> I think part of the problem is WordPress plugins compete with each on features and need even more features on top to charge for the premium version, so page speed and robustness via simplicity get lost in the noise.

I agree, that looks like part of the reason for bloat, but most have also evolved over years. Most successful plugins have been around for a decade or so, and few people talked about web performance in 2010. That many authors initially just solved their own problem while learning php and shared their solution plays a part as well (not to mention that they often started writing them on php4).

Post reply on HN