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

191–200 of 371 posts

Re: Whitehouse.gov Chooses WordPress, Again

#191

Post by ehnto »

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…

I have been thinking about what solution is for this. Do you think users would be happy with a WordPress backed headless app?

The other issue is that visual content editing in WordPress is pretty tricky. Site owners want cool modern design, but editable in the WordPress admin, and meeting them in the middle has proven difficult using Gutenberg. They often find the new UI brittle and difficult to work with, even for core WP blocks. The developer experience is also pretty cumbersome.

If anyone has found an idiomatic approach that works, I'd love to hear it!

Re: Whitehouse.gov Chooses WordPress, Again

#192

Post by newsbinator »

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…

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

Re: Whitehouse.gov Chooses WordPress, Again

#193

Post by ehnto »

trog wrote: post #101
splatzone wrote: post #79

Earlier quoted context omitted.

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…

> 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. Curious as to how you manage WP with git, particularly around when new files are added by core/plugin updates, which I've always found a bit of a hassle to deal with?

Disable automatic updates on production. You don't want automatic updates on a production site anyway, they could bring your site down without you knowing. Instead, install updates and plugins locally, test locally, then push to live. That's really true for any code versioned software.

Re: Whitehouse.gov Chooses WordPress, Again

#194

Post by 42droids »

Kimitri wrote: post #164
captn3m0 wrote: post #158

Earlier quoted context omitted.

Wordpress is also the only CMS that offers multisite hosting - single codebase, single webserver, one docker container - for running multiple sites with different configuration. You wanna run 2 blogs on Ghost - run 2 instances, same for _everything but Wordpress_.

Well, Drupal has multisite capability, too. I don't think using multisite is actually that good an idea. Having two separate websites be dependent on the same codebase is very prone to cause serious life cycle problems. I'd advice against using multisite on WP or Drupal.

We have been doing this successfully for many years, no problems. Some multi site installs have up to 300 sites running on them. You have to know when to use the available technology.

Re: Whitehouse.gov Chooses WordPress, Again

#195

Post by draw_down »

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…

I really love that you said this. It’s such a great example of what I keep saying, that “simplicity” is more about what one likes or prefers rather than describing some actual sort of elegance of design.

“Simplicity” does not really refer to a property of the subject in question, it’s a reflection of one’s attitude toward the subject.

Re: Whitehouse.gov Chooses WordPress, Again

#196

Post by ehnto »

nsomaru wrote: post #159
splatzone wrote: post #79

Earlier quoted context omitted.

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…

> I prefer to version sites with git and install updates locally, then git pull down on to the live server. I’m working on my first WP project and am trying this approach. A question I have is how do you handle plugins that have hooks that only run once when installed? Those hooks don’t run if you pull in via git. Also if they make changes to the dB (migrations), how is that managed if the plug-in was installed on a…

That is all usually still triggered even when using git. Git doesn't manage the database, so when the files make it to production and the plugins are activated, they see a database they haven't been installed in and then correctly run their hooks. Same for migrations. Migrations are managed with database entries, so if your production database doesn't have those entries, it will still run the migrations.

You can check out WP CLI to automate some of this as well.

Re: Whitehouse.gov Chooses WordPress, Again

#197

Post by hmillison »

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…

I built out a site using headless WP with Next.js as the frontend. With server side rendering of React, we still took advantage of caching the HTML in a CDN like you would with vanilla WP but it was much easier to build our own theme as desired with React.

While configuring certain parts of Wordpress was tricky at times, especially because deploying it is at odds with the stateless nature of modern containerized infra. Particularly plug-in installation with WP cli requirng a DB connection which makes it tough to fully configure your installation at container build time. I still think it struck a balance between developer experience and a good experience for the content team.

Re: Whitehouse.gov Chooses WordPress, Again

#198

Post by sleavey »

nsomaru wrote: post #159
splatzone wrote: post #79

Earlier quoted context omitted.

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…

> I prefer to version sites with git and install updates locally, then git pull down on to the live server. I’m working on my first WP project and am trying this approach. A question I have is how do you handle plugins that have hooks that only run once when installed? Those hooks don’t run if you pull in via git. Also if they make changes to the dB (migrations), how is that managed if the plug-in was installed on a…

As far as I know there aren't any real hooks available for running code on plugin install, only activation. But I think OP is referring to core WordPress code and not plugins.

Re: Whitehouse.gov Chooses WordPress, Again

#199

Post by trog »

nsomaru wrote: post #186
trog wrote: post #176

Earlier quoted context omitted.

> The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it. Regular reminder that wordpress.com is a different software product to wordpress.org :) wordpress.com runs their (relatively) newer JavaScript-based stack; wordpress.org (which is what we're talking about here, unless I misread the article referenced here completely) is the LAMP stack version.

Unless the new Wordpress is written in node, comparing the new “JavaScript” stack with the old “LAMP” stack makes no sense to me. Those technologies do not serve the same purpose.

> Unless the new Wordpress is written in node, comparing the new “JavaScript” stack with the old “LAMP” stack makes no sense to me. Those technologies do not serve the same purpose.

It's written in JavaScript; it runs on node.js - at least the front-end part of it (https://github.com/Automattic/wp-calypso). I don't know what is running on the backend but I don't think it's LAMP?

The point I was making though is that "WordPress" can mean two different things - wordpress.org (the self-hosted LAMP version) or wordpress.com, which is a SaaS offering (so the language is more or less irrelevant unless you're really interested in running your own admin frontend, I guess).

Re: Whitehouse.gov Chooses WordPress, Again

#200

Post by ehnto »

ellyagg wrote: post #124
splatzone wrote: post #117

Earlier quoted context omitted.

I keep things really simple to be honest, normally I exclude wp-content/uploads and wp-config.php in .gitignore. And set the perms so WP can't write to the filesystem on production, except for the uploads directory. We install and test updates on a dev environment first then commit everything and pull it in on production.

If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?

If your using a versioned codebase you likely don't want that anyway. Otherwise you'll have untested code on production, and you'll have to commit it to the project repository from production.

Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.

It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.

Post reply on HN