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

Whitehouse.gov Chooses WordPress, Again

pagely.com

Post reply on HN
Print view View original

201–210 of 371 posts

Re: Whitehouse.gov Chooses WordPress, Again

#201

Post by 867-5309 »

thayne wrote: post #45
westoque wrote: post #4

I hope we again see the value of using systems like Wordpress for it’s simplicity in getting a blog/website setup and easily modify content. Lately most of the modern marketing websites I see is built using gatsby and next.js. Having been talking to different content/marketing teams, they hate it so much because of the complexity it brings. Editing content? Sign in to this headless CRM app, want a form? Go sign in to…

From an operations perspective, gatsby and next.js are much simpler though. You are just deploying static content behind a webserver or even something like s3. Horizontal scaling is almost trivial. With wordpress though, you have to worry about a database as well, scaling is more complicated, you need to run php on your webservers (which has security implications), updates that include schema updates frequently requi…

>you need to run php on your webservers

are you suggesting to run it remotely? on even a small site the performance impact would be noticeable. also, you'd then be securing two systems instead of one

Re: Whitehouse.gov Chooses WordPress, Again

#202

Post by tomduncalf »

newsbinator wrote: post #192
coldtea wrote: post #150

Earlier quoted context omitted.

> Simplicity? Perhaps in its use, but not the code. Nobody but other devs cares about the simplicity of the code if the code works. > The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening. Huh? Wordpress/PHP hosting requirements are the easiest to meet in the industry. Not to mention the most widely available... > ~~You have to~~ WP expect you to install it such that it can modi…

> Nobody but other devs cares about the simplicity of the code if the code works. They care when you start quoting a week for a simple addition that should take an hour, because every time you have to wade into a mess, in which one wrong semicolon in functions.php brings down the entire website. Of course you test and you test, but you're surrounded by landmines at all times.

> They care when you start quoting a week for a simple addition that should take an hour

Exactly, this is the key point. If it’s a website that literally will never change then fine (edit: what I mean here is if you are confident WP can meet your needs without resorting to hacks, and can meet your future needs - in my experience, it’s when more functionality gets added on by random developers that things get messy, true of development in general though!).

I guess using headless WP might help? The clients I’ve worked with who’ve had WP sites in the past have made a point of saying they definitely don’t want WP again (due to security nightmares, usability etc) so honestly haven’t investigated it too deeply recently.

Re: Whitehouse.gov Chooses WordPress, Again

#203

Post by ssijak »

wvenable wrote: post #183
jaza wrote: post #115

Earlier quoted context omitted.

I was a Drupal dev for ~10 years. Once upon a time, I built many sites with it, and I recommended it to many folks. Despite its flaws (and it always had flaws), it was a great piece of software in its heyday, and it had (and still has?) an amazing community. I'd still choose it over WordPress any day. But the days when I'd recommend either of them (or indeed anything in PHP) are long gone. Your best bet now is probab…

Does no one else ever have users want to setup content to go live at specific dates and times? Static site generators are great for truly static content but that's extremely rare anywhere where content is frequently edited.

You just use a headless cms that have post scheduling. Like Prismic for example.

Re: Whitehouse.gov Chooses WordPress, Again

#204

Post by tomduncalf »

rapind wrote: post #95
tootie wrote: post #55

Earlier quoted context omitted.

A pretty standard stack I've done recently is Netlify, Gatsby (I'd lean next at this point) with Prismic, Hubspot and GTM. It's barely more investment to setup than WordPress but lets you build something visually sophisticated really easily and you get user friendly CMS, CRM and all the analytics and user engagement stuff. And running headless means there's almost zero attack surface.

Which CMS were you using though? Netlify CMS? Last I looked at it, there was a lot to be desired (not to belittle their effort, but not even close to WP in terms of functionality). Worth mentioning you can also run WP headless and build your front end in w/e js framework du jour you prefer.

They mentioned Prismic, so I assume they are using that as CMS

Re: Whitehouse.gov Chooses WordPress, Again

#205

Post by achairapart »

falcolas wrote: post #99
rapind wrote: post #93

Earlier quoted context omitted.

> A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service. I'm not a big WP fan, but this statement is false in most cases. Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk (or CDN) without hitting PHP. Pagely (the post we're discussing) even…

> Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk I'd be very curious how a WP plugin is managing this. Third party hosting building in caching, normal in-line caches (like Varnish), nginx/apache caching, sure - I get those, and they behave how you say. But a WP plugin? I'm curious how that would bypass PHP & WP entirely.

Server rewrites. Usually they work adding rules to Apache .htaccess.

On the other hand, this trick was mostly useful years ago when shared hosting plans were really underpowered.

As of today, with improvements of both PHP 7.x and general server performance, even a cache system that uses PHP very early (before any DB connection) to load a pre-rendered html cache file goes a long way in terms of number of pages being served.

Actually, if this become your bottleneck, the .htaccess trick won't help a lot, and you would still look in tools like memcached, redis or reverse proxies to improve things.

Re: Whitehouse.gov Chooses WordPress, Again

#206

Post by eecc »

coldtea wrote: post #150
falcolas wrote: post #61

Earlier quoted context omitted.

Simplicity? Perhaps in its use, but not the code. The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening. ~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare. It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request. It falls apart under any…

> Simplicity? Perhaps in its use, but not the code. Nobody but other devs cares about the simplicity of the code if the code works. > The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening. Huh? Wordpress/PHP hosting requirements are the easiest to meet in the industry. Not to mention the most widely available... > ~~You have to~~ WP expect you to install it such that it can modi…

Well it’s a security shitshow and a fav for hackers looking for an easy exploit vector: just compromise it once and voila! All website consumers are at risk.

Just a shame there’s no liability for negligently causing users to get infected.

Re: Whitehouse.gov Chooses WordPress, Again

#207

Post by pfranz »

centimeter wrote: post #162
imwally wrote: post #62

I was curious after seeing the accessibility statement what the previous administration's had. https://www.whitehouse.gov/accessibility/ https://obamawhitehouse.archives.gov/accessibility https://georgewbush-whitehouse.archives.gov/accessibility.ht... https://trumpwhitehouse.archives.gov/accessibility With that last one not being surprising at all.

What is the point of this page besides signaling? It seems completely useless from an informational standpoint.

All of those pages I looked at cite specific things they intend to support (alt tags, text resize) and give a way to reach them. If something stops working, which is incredibly common over a 4-8 year span, a user knows they should be working and have a way to reach out.

Ideally, appropriate accessibility features would just be expected. I'm not intimately familiar with web accessibility, but webaccessibility.com (a random site I found) ranked the landing page for the last three administrations in the mid-to-high 80s.

Re: Whitehouse.gov Chooses WordPress, Again

#208

Post by kilroy123 »

modernerd wrote: post #188
monoideism wrote: post #89

The one thing great about WordPress is the massive number of themes available (and plugins, if you're not a programmer). I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain. And yes, you can design them, but it takes more time and most programmers don't have the design chops to pull it off.

Do you think there’s a market for high quality paid themes for static site generators like Hugo?

I think there's a small market. I've gone looking for high quality hugo themes before. I was willing to pay for one.

Re: Whitehouse.gov Chooses WordPress, Again

#209

Post by AlchemistCamp »

falcolas wrote: post #87
winrid wrote: post #81

Earlier quoted context omitted.

I've been in the top 10 of HN and I think I saw at most 10-20RPS. My $5/mo VPS running WordPress can handle about 50rps for an article page...

Huh. That's a lot lower than I expected for a high ranked HN post. I'll agree, WP didn't start having issues until the 50-100+ range.

My site has also hit #2 on HN multiple times and never broken 10RPS during any of those times, AFIK.

Re: Whitehouse.gov Chooses WordPress, Again

#210

Post by kirstenbirgit »

falcolas wrote: post #99
rapind wrote: post #93

Earlier quoted context omitted.

> A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service. I'm not a big WP fan, but this statement is false in most cases. Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk (or CDN) without hitting PHP. Pagely (the post we're discussing) even…

> Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk I'd be very curious how a WP plugin is managing this. Third party hosting building in caching, normal in-line caches (like Varnish), nginx/apache caching, sure - I get those, and they behave how you say. But a WP plugin? I'm curious how that would bypass PHP & WP entirely.

>I'd be very curious how a WP plugin is managing this.

If you don't know how the cache plugins do this, it's pretty obvious you are not very knowledgable about WordPress site operations. Please stop spouting falsehoods here.

Post reply on HN