Live data from Hacker News

Whitehouse.gov Chooses WordPress, Again

pagely.com

71–80 of 371 posts

Re: Whitehouse.gov Chooses WordPress, Again

#71
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.

I was surprised that the accessibility widget on the current website has a feature called “high contrast mode” that does not significantly increase the contrast ratio between the primary text and the background. It also significantly lowers the contrast between the secondary text and the background, sometimes as low as 2.1 (7 is the recommended minimum).

Given the icon they chose, it seems like “dark mode” would be a more appropriate name.

Re: Whitehouse.gov Chooses WordPress, Again

#72

Earlier quoted context omitted.

> just a single file zipped up or scp'd And now your page displays a white page. Error in the log is an exception with no stacktrace/location. This was my experience in production a few times. It's a fun system if it works, but without a testing pipeline and a staging environment it's a lottery with a possible mystery breakage on every update/change.

> It's a fun system if it works, but without a testing pipeline and a staging environment it's a lottery with a possible mystery breakage on every update/change. That describes every platform, programming language, layer of the stack, etc. that I've ever worked with.

At the end. All of our tooling sucks. Although I have to say generally the apache error log guides me to the right place.

Re: Whitehouse.gov Chooses WordPress, Again

#73

Earlier quoted context omitted.

Yes because Wordpress includes frontend rendering (of both the actual pages and the backend admin) by default. This means you get working HTML powered by dynamic content out of the box, and it keeps working as content changes without needing constant builds for static sites. I see the benefits of modern component-driven frontend systems but I think the better opportunity would be to integrate this cleanly into existi…

Wordpress also has a really rich ecosystem of mature and widely used plugins that are quite easy to install. The podcast ones for instance, they'll allow you to schedule the publishing of a new episode, then upload the episode to all the major platforms, format the images, titles and descriptions automatically for the different platforms, cross post to the social media accounts announcing the new episode, allow you t…

I excluded plugins because additive functionality and ecosystem are independent of the core product, but yes Wordpress (and server-side apps) can be extended to do much more than a plugin in a static build process.

Re: Whitehouse.gov Chooses WordPress, Again

#74
post #54

Earlier quoted context omitted.

Governments should moderately prefer self-hosted solutions to cloud services, especially when a president just got banned from all social media platforms.

The SolarWinds hack is another cautionary tale about not self-hosting.

Not really. What guarantee do you have that your cloud hosting provider wasn't also running SolarWinds services behind their firewalls.

Re: Whitehouse.gov Chooses WordPress, Again

#76

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…

> You have to let it modify its install. Security-fucking-nightmare. You really don't. I've deployed it to Heroku, where the filesystem resets every 24h. It's a part of their famed five minute install for not-very-technical users on shared hosting, but it's by no means a requirement.

It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades.

We disabled it (except for the attachments folders), and boy did it throw up all over the logs.

Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.

Re: Whitehouse.gov Chooses WordPress, Again

#77

Earlier quoted context omitted.

> You have to let it modify its install. Security-fucking-nightmare. You really don't. I've deployed it to Heroku, where the filesystem resets every 24h. It's a part of their famed five minute install for not-very-technical users on shared hosting, but it's by no means a requirement.

It is if your users expect to be able to add plugins themselves , or you want it to do automatic version upgrades. We disabled it (except for the attachments folders), and boy did it throw up all over the logs. Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.

> It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades.

I'm fairly certain for the White House's sort of use case this is not an issue.

> Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.

We did not permit it to have write access to its own filesystem, at all. It worked fine. Uploads went straight to S3 via a plugin.

Re: Whitehouse.gov Chooses WordPress, Again

#78
post #15

I'm disappointed by their choice in site design and I'm sure it'll be infuriating to interact with for those with disabilities. It's a real wasted opportunity to use this instead of something more battle tested and fit for purpose such as the design used by the gov.uk site. https://www.gov.uk/ https://www.gov.uk/guidance/government-design-principles/

I'm not sure what I'm supposed to get from looking at gov.uk. For me, it was a negative experience, and I'm glad it's not used in the US.

Re: Whitehouse.gov Chooses WordPress, Again

#79
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…

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…

WordPress is not without its design flaws, some of which make sense from the point of view of helping non-techies run their own sites (such as making updates easy.) But as someone who has built 100s of sites with WordPress I feel the need to defend it on a few points here:

> You have to let it modify its install. Security-fucking-nightmare.

You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.

> It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.

A good practice is to set up your own cron job[1] on the server and disable the internal cron in your wp-config.php, like this:

  define('DISABLE_WP_CRON', true);
Again this is a decision I imagine was made to support shared hosting environments. They've made it easy for 99% of users, which is why it's so popular. We the remaining 1% who prefer to use real cron can edit the config.

> It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.

Just install a page caching plugin of your choice[2]

> You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.

Or use a managed WordPress hosting service like Kinsta[3] if you don't want the hassle. They'll handle all this sysadmin faff for you...

[0] https://wp-cli.org/

[1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-j...

[2] https://en-gb.wordpress.org/plugins/w3-total-cache/

[3] https://kinsta.com/

Re: Whitehouse.gov Chooses WordPress, Again

#80

Earlier quoted context omitted.

It is if your users expect to be able to add plugins themselves , or you want it to do automatic version upgrades. We disabled it (except for the attachments folders), and boy did it throw up all over the logs. Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.

> It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades. I'm fairly certain for the White House's sort of use case this is not an issue. > Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours. We did not permit it…

> I'm fairly certain for the White House's sort of use case this is not an issue.

One can only hope.

> We did not permit it to have write access to its own filesystem, at all. It worked fine.

Cool beans - you installed it sanely. But contrary to how WP expects to be installed. I've corrected the original statement.

Post reply on HN