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

341–350 of 371 posts

Re: Whitehouse.gov Chooses WordPress, Again

#341

Post by hardwaresofton »

marc_io wrote: post #259
hardwaresofton wrote: post #127

Earlier quoted context omitted.

I think if WP ever finds a way to do two things: - continuously serialize WP to static files - Make it easier to work with Wordpress as a CRM (No Code or at the very least don't force developers to touch PHP) JAM stack would near instantly cease to make any business sense (though developers would still love using it of course). A lot of the issues with Wordpress are sort of long-tail -- combinations of plugins exposi…

> continuously serialize WP to static files Any cache plugin for WordPress does this already, but if you mean something that does this in order to host elsewhere (like in Netlify), WP2Static is a solution.

Ah thank you -- WP2Static is something I didn't know about.

Do some cache plugins actively walk your site and generate the pages? How do they handle when user login plugins are present? I'd expect a naive/basic caching plugin to add to the cache when a page was visited, not necessarily ahead of time.

Re: Whitehouse.gov Chooses WordPress, Again

#342

Post by hardwaresofton »

ozorOzora wrote: post #185
hardwaresofton wrote: post #127

Earlier quoted context omitted.

I think if WP ever finds a way to do two things: - continuously serialize WP to static files - Make it easier to work with Wordpress as a CRM (No Code or at the very least don't force developers to touch PHP) JAM stack would near instantly cease to make any business sense (though developers would still love using it of course). A lot of the issues with Wordpress are sort of long-tail -- combinations of plugins exposi…

Or you can just roll with JAMstack as it's literally about what you're asking for.

The problem I'm saying exists with JAM stack is that it's great for developers but bad for non-technical people -- wordpress is the opposite, and if I could get JAM stack properties out of Wordpress, I wouldn't use JAM stack for any projects which involved having non-technical people modify the site (which is a lot of them).

Re: Whitehouse.gov Chooses WordPress, Again

#343

Post by photomatt »

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.

What's funny is that this error would have been impossible to make within WP's built-in file editor. It lint checks before letting you save any edits.

Re: Whitehouse.gov Chooses WordPress, Again

#344

Post by folkrav »

snowwrestler wrote: post #283
YetAnotherNick wrote: post #239

Earlier quoted context omitted.

How do you test wordpress without deploying it? \s

This conversation is feeding my suspicion that a lot of the problems people have with Wordpress come from not knowing how to work with Wordpress. The professional approach is a local copy for development, a staging copy on hosting for QA, and then production. Code goes up in deployments; DB and files come down in regular synchronization. If there are multiple devs you might also have an integration copy on hosting. T…

I've worked in environments using the exact approach you described, and it definitely seems like the prevalent workflow using these CMSs.

Still doesn't help that most WP sites I've ever seen inevitably were those huge card castles just waiting to crumble at the next plugin update. Cause of course, the remarketing plugin the client needs/wants installed just introduced some weird edge-case bug when used in combination with the latest version of the forms plugin you use. Or they ask (demand) administrative privileges "cause they're paying" and proceed to start messing with the configuration themselves and destroy everything. All the local development copies in the world won't make it less temperamental and brittle.

Its success - IMHO - doesn't have much to do with its technological merits but familiarity. Most "content" people know how to use WP, so companies like to have WP for their content management.

Or maybe I'm just bitter of my time working in the kind of environments that tend to focus on WP. Although last news I got were they were starting to use it more as headless CMSes.

Re: Whitehouse.gov Chooses WordPress, Again

#345

Post by snowwrestler »

laumars wrote: post #333
snowwrestler wrote: post #286

Earlier quoted context omitted.

> Security wise, any popular CMS will be a security nightmare. I disagree, and I think it comes from a different understanding of what web security is. Popular CMS software benefits from millions of people hammering on installations. If the community constructs a sane process for handling vulnerability reports (and WP has), then the average user of that software benefits from a robust continuous testing regime that t…

You’re overlooking a key thing there though. You’re assuming every hack is a targeted one. And that simply isn’t the case. Whenever a new vulnerability is discovered for WP (or any popular suite, be it a shop like Magento or message board like phpBB) you then get hordes of bots that trawl the internet looking for sites that run out of date versions of said software just for the purpose of hacking it. Even search engi…

It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that.

We always aimed to evaluate security patches same-day. The shortest lag we saw was “Drupalgeddon”—about 12 hours. In some cases we would see a lag of up to a month between the release of a patch and the signatures of automated attempts to exploit the underlying vulnerability. We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts.

I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.

I guess it’s true that if someone is going to be bad at running a website, a popular CMS might be a bad experience for them. But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.

Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.

Re: Whitehouse.gov Chooses WordPress, Again

#346

Post by photomatt »

laumars wrote: post #331
coldtea wrote: post #291

Earlier quoted context omitted.

> The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud. There's no "NFS requirement for multiple Wordpress hosts" tho.

In theory that’s true but in practice there needs to be a common file system for WP to function properly otherwise you end up with a lot of kludges that break the admin panel or that adds other caveats to WPs normal behaviour.

I wouldn't suggest it personally, and don't think it's common.

Re: Whitehouse.gov Chooses WordPress, Again

#347

Post by photomatt »

DigitalSea wrote: post #240
42droids wrote: post #194

Earlier quoted context omitted.

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.

Spot on. I am currently working on a project that has over 25,000 multisites running in WordPress Multisite. The amazing thing besides the sheer number is WordPress has not been a problem, throw it on AWS and the scaling issues are solved. People who proclaim that WordPress can't scale have never built anything scalable with it.

Awesome example, thank you for sharing!

Re: Whitehouse.gov Chooses WordPress, Again

#348

Post by marc_io »

hardwaresofton wrote: post #341
marc_io wrote: post #259

Earlier quoted context omitted.

> continuously serialize WP to static files Any cache plugin for WordPress does this already, but if you mean something that does this in order to host elsewhere (like in Netlify), WP2Static is a solution.

Ah thank you -- WP2Static is something I didn't know about. Do some cache plugins actively walk your site and generate the pages? How do they handle when user login plugins are present? I'd expect a naive/basic caching plugin to add to the cache when a page was visited , not necessarily ahead of time.

This depends on the plugin or cache system being used, but it can be done ahead of time, yes. Generally, the cache is created on the first visit and purged when a change occurs. Highly dynamic pages can be excluded from the cache by default, like the login or the cart page on an E-commerce website. Some solutions even allow to change the caching period for specific parts of the code, on the fly (fragment caching).

Re: Whitehouse.gov Chooses WordPress, Again

#349

Post by photomatt »

sixothree wrote: post #316
uberswe wrote: post #307

Earlier quoted context omitted.

Pretty much any shared hosting can support Wordpress. Kinsta was a suggestion where you pay for someone to manage and install things for you which is a lot more than hosting.

Right. I have a shared hosting site I used to host some projects on and now I keep it solely for a single wordpress site for a relative. My thinking was a wordpress-specific provider might be cheaper so I went out looking for one with disappointing results. `

Happy to host your relative's site on WP.com, here's a 50% off coupon for HN peeps that will work the next 48 hours: HNEWSJANMATT . Please tweet me if you want any extra help from our team on the migration. I hope your relative is very happy.

Re: Whitehouse.gov Chooses WordPress, Again

#350

Post by photomatt »

trog wrote: post #199
nsomaru wrote: post #186

Earlier quoted context omitted.

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 tha…

We run WordPress multi-site on WP.com to power several hundred million user accounts. So whenever you visit a domain hosted by us, you're hitting 99% core WordPress, plus some custom plugins and code we run to make it multi-datacenter and super-secure.

Calypso is our JS dashboard that lets you manage all your sites in one place, plus get cool WP.com features like stats and notifications. It's just a REST API client, just like the iOS and Android apps.

Post reply on HN