8 ms·

This, to me, is the main reason why it's a bad idea to host and maintain a presence with a CMS yourself. Most likely you are not an entity that has the capabili

• lsc 9y ago
  Seems like the right thing to do for most CMS type situations is something that generates the site offline... and only uploads a static site to the web. Something like jekyll or something.
  • sphix0r 9y ago
    This. Most websites are mainly read only anyway. No need to throw in a programming language and store the data in a database. The thing is, non-tech savvy people should be able to use(and deploy) and understand the static-web generators.
  • Roritharr 9y ago
    That's of course a good solution but then you want your Ajaxy Web 2.0 Things in there, some more complicated forms maybe and you start looking at something that takes quite some effort to build compared to what you get from WordPress/Drupal etc. Funnily enough, having worked on all kinds of websites for the past 15 years, i'm still at a loss when asked what the all-round good solution is.
    • andybak 9y ago
      Maybe the problem is the phrase "all round". There are trade offs to be made and complex cost/benefit calculations that are required. To further complicate things, things change. A website that was a perfect fit for a Wordpress template easily grows beyond that. And a site that seemed ideal for a custom Django/Rails backend might eventually settle into the kind of functionality groove where you begin to wonder if an off the peg solution might not have been a better idea.
    • jlgaddis 9y ago
      WordPress at least automatically updates itself. There's been a few times when auto updates broke but, overall, it has been a tremendous help in reducing the number of exploited web servers out there.
  • stephenr 9y ago
    Im pretty convinced static site generators should be the default first choice for most sites.
    • bonesss 9y ago
      Especially if you're popular and want to scale. Turning that CMS into a distributed publishing platform is tricky, but scaling static content is easy-mode from top to bottom.
    • StavrosK 9y ago
      I've recently found the perfect middle ground: Django with Wagtail and Bakery. Django is Django, Wagtail is a very well designed CMS, and Bakery allows you to export Django views as static files. That way, I managed to convert my dynamic website to a static one with a few lines of code (basically a loop that iterates over all URLs on my site).
  • jmknoll 9y ago
    I'm a big fan of Jekyll (and more recently, Gatsby), and I think you're correct in saying that in most cases where a CMS is used, a static site generator would be a better option. However, I see a couple of problems standing in the way of more widespread adoption of static site generators: 1) I've never seen a static site generator that non-technical users felt comfortable with. Programmers like terminal interfaces. Your average user in 2018 has probably never opened the terminal. 2) Possibly even more significant, I don't think the people making the choice to use a CMS for a simple business-info or blog site are aware of the trade-offs that they're making, or of the benefits that a static site will provide down the line. For a lot of small business owners I've spoken with, Wordpress is basically synonymous with "web presence." I wonder if there's a market for a web-based GUI like what Wordpress provides, but which runs jekyll under the hood and uploads the files to s3 or something like that. Is this what companies like Squarespace and Wix do?
    • benaiah 9y ago
      The project I work on, Netlify CMS (https://www.netlifycms.org/ https://www.netlifycms.org/), is almost precisely what you described in your last paragraph.I say "only" because it only officially supports GitHub as a backend at the moment, from which you can deploy to a host. (I'm also currently working on supporting more backends, so that will change soon.) The CMS is an open-source (MIT license) CMS built as a static web page which connects to an API for an arbitrary backend from your browser and edits the content stored there - from there, you can build the content with whatever static site generator you want. This lets you build sites that non-technical users can keep up-to-date without tying yourself to a specific tech stack for the actual website. (disclaimer: Netlify employee)
      • StavrosK 9y ago
        Please put that description somewhere on the site. I tried to try out Netlify CMS there times because I love Netlify the service but couldn't figure out what it is any of those times. That said, it didn't help that you don't support Gitlab, which is where all my sites are, and which is the more important reason why I couldn't get it to work.
  • scandox 9y ago
    Whenever I try to sell this internally we fall down on plugins. Marketing are using hundreds of them that we can’t replicate.
    • arbie 9y ago
      Hundreds!? Is there significant overlap in their functionality?
      • scandox 9y ago
        I have no idea. We more or less took one look at all the crazy sh*t they were doing with pixels, trackers, inbound marketing, outbound marketing, SEO, sitemaps, special codes for FB, GA, dynamic landing pages... You know it's all trivial garbage...except if you want to replace it you need to support it, train them to use these tools and at every point you're going to encounter this resistance about WHY you're doing it and you say well security and speed and they're like it's fast enough and we've never been hacked. So until the site grinds to a halt and they get also get hacked they basically view you as a blocker.
  • tenken 9y ago
    Grav CMS is interesting.
    • pathartl 9y ago
      I've always wanted to try it. I'm more interested in Statamic which is premium, but seems better supported and I'd be more comfortable putting clients on it. From an outside perspective without having used either, that is.
  • arca_vorago 9y ago
    As a sysadmin who has seen and fixed drupal/wp/joomla/dreamweaver etc nightmares, I personally have settled on a combination of emacs org-mode html export (don't forget how beautiful the latex export can be!, and that you can run programs inside org-mode, and the google calendar integration, etc) and asciidoc and asciidoctor(nicer default html export settings, but I suggest custom pure css3/html5 no js!). That said, back on subject: Look, this is the main reason you devs tend to hear disdain from us sysadmins when we hear you want to run some new webservice in whatever language fad of the day (node, python, perl, php, asp.net, ruby, scala, go, etc) instead of generating files with your app that can then be serviced to the user using the tried and true tools (apache, nginx, hiawatha, haproxy etc) that have had sometimes decades of public internet exposure to claw thier way through. Ah, but what about $functionality. Most webdevs think they need a scripting language backend when they really don't. There are uses for it and it has it's place, but it's been way overdone. Relevant discussion: https://groups.drupal.org/security/faq-2018-002 https://groups.drupal.org/security/faq-2018-002 Sidenote: I think everyone should check out hiawatha webserver, over at (https://www.hiawatha-webserver.org/ https://www.hiawatha-webserver.org/). Hugo wrote it with security in mind and it by default addresses many things that no other webserver does. It's also gplv2 (which is a big deal for me), and it's performance is second to none. I'm not a big php person, but if I were to be doing a webapp where a backend like that would be needed, I would probably try to go PHP-FPM with hiawatha(mbed TLS)/haproxy and a really nicely hardened boxen and edge firewall(you are using nftables now right?).
    • indigodaddy 9y ago
      Source for the Hiawatha performance claim?
      • arca_vorago 9y ago
        Well it's a bit old now but a few years ago on the Hiawatha blog a test of load under attack was done and Hiawatha was able to handle a simulated (d?)dos very well. I'm on mobile but a quick ddg show: https://www.hiawatha-webserver.org/weblog/64 https://www.hiawatha-webserver.org/weblog/64
    • 9y ago
  • bastawhiz 9y ago
    Somewhat tangential anecdote: I used to work a LONG time ago for a company that built Yahoo Small Business ecommerce websites. They used a tool called RTML ("Robert T Morris Language"), which was essentially HAML, powered by Perl, and constructed using a GUI (no text editor interface). Select where you want a node > New node > select node type > Save...each action was a full page load. The process was excruciating, and I was in charge of developing tools to automate the upload of "template" files from the developer's machine to the client's Yahoo Small Business store. At the end of the day, the customer would load up all their goods into the Yahoo database and hit "Publish", at which point a multi-hour job would kick off to run their RTML against the database. The result was a completely static ecommerce website. Only the cart/checkout pages were dynamic, and those were using shared code. The development process was a nightmare. The client experience was really bad (want to fix a typo? You're going to wait a couple hours). But I'll be damned if it was possible for anyone to hack those things. There was nothing to hack.
  • dreamfactored 9y ago
    That's how the early CMS's like Vignette worked and they evolved to solutions like WP and Drupal which are better for the web publishing use case - easier to maintain, develop, and capable of real-time UGC and publishing (real-time is crucial for SEO in commercial publishing). Static site generators are simply a file-system caching layer. Drupal used to have one of those and it was a terrible idea as the number of page variants on a commercial site very quickly hits file-system limitations and performance is appalling. Better to use a proper CDN for a similar result but with massively reduced latency due to content being served from the edge.
• TekMol 9y ago
  > It takes a relatively large team to reliable shield software as complex as modern CMS from abuse No. The article is about a security holes from 2014. It does not need a team to keep your software updated. I have been running a bunch of CMS for many years now and keeping them updated takes me almost no time. If I accumulate all the time I spent on it, it's probably a day per year or so.
  • Operyl 9y ago
    The article references holes from 2014, but was primarily talking about the most recent one in March of 2018.
    • TekMol 9y ago
      My mistake. But it still holds that keeping a single system up to date takes like a few hours a year max. The updates themselfes are usually done in minutes. Only once every few years there will be some issue that takes you some hours to deal with.
      • Roritharr 9y ago
        Once is enough though. Most entities aren't equipped for 8 hour turnaround times to update something that can be 24/7/356. Think about all the schools that paid someone once for this. The Solution is easy but the structure of responsibility is not there.
        • TekMol 9y ago
          Schools? Hmm... it's a bad idea to host and maintain a presence with a CMS yourself I would have thought saying so on Hacker News addresses the readership of Hacker News. Aka myself. So I objected. Talking about schools. I would say it depends. If the kids run the CMS I would say the learning outweights the downsides of having some VM hacked that only holds public information. So for a CMS with public information I would say: Let the kids have fun with it! There might also be use cases where that's not a good idea. Really depends on what the CMS is used for.
• fabian2k 9y ago
  The original Drupalgeddon vulnerability was seriously problematic in the speed of exploitation. The automated exploits were developed only hours after the announcement, and ~7h later as far as I remembered widespread enough to consider all unpatched installations compromised. This exploit was far more lenient in timing, there was an advance notice of a serious vulnerability, and the automated exploits were weeks later this time. There are certainly many people running a CMS themselves that don't have the capabilities to keep them reasonably secure. But it's not that hard if you have a reasonably small attack surface, e.g. few plugins and no user-generated content/accounts. And of course you need to subscribe to the relevant security mailing list.
  • Roritharr 9y ago
    Sure I could run a CMS reasonably secure Drupal Site. But I'm at a successful startup, have had years of experience hardening Websites and know my it-sec hygiene. This also makes me not the target audience for CMSes like Drupal. Most of us agree that having static site generators are a much better solution for most use-cases. The people needing WordPress and Drupal don't know what Usecases they need, they are exploring the possibilities often times.
• stesch 9y ago
  My last employer didn't understand this. Currently they have to deal with at least 5 different CMS, 4 shopping systems, and some hand made sites with at least 4 different frameworks. 2 backend languages. And legacy code with self written frameworks in PHP 4 on at least 2 important sites.
• borplk 9y ago
  Yes and people don't understand this. If you try to bring it up there's always some inexperienced overseas contractor with 6 months of experience who will say "It' s a few clicks to install and a few plugins to protect the security 100% no problem, what's so difficult? why do you make a big deal out of it?".
  • bhldr 9y ago
    Say hypothetically if a got my Drupal site for cheap and now I'm hacked. I pay someone another $100 to install the patch and get rid of the malware, I still come out ahead. What's my incentive to do things differently?
    • homero 9y ago
      Defacement of your site, Google delistment for hosting malware, email blacklist for spam
      • treve 9y ago
        I've seen plenty of sites survive these types of exploits just fine.
        • zamber 9y ago
          Still, I for one wouldn't want to be on a receiving end.
    • Roritharr 9y ago
      That's like asking, what's the worstcase of my email account being hacked? There's a spread between your life is ruined and nothing happens at all and it entirely depends on what you've done with the account/site.
    • thaumaturgy 9y ago
      > and get rid of the malware This is the catch. Depending on what was done to your site, there's no "getting rid of the malware" for $100. Those cheap hosting providers don't provide automated backups of your database. You probably have a backup of your site's files -- that's probably not perfectly current, but close enough maybe -- but I bet you haven't got regular backups of your database. Drupal is one of those many CMSs that stores tons and tons of code in the database, including executable PHP. So how do you go about ensuring that all of that is clean, and changing all the passwords that may've been compromised, and making sure there are no other backdoors or shells left behind, for $100?
• avttre 9y ago
  Windows gets exploits too, but that doesn't mean it'd be a good idea to replace it with Chrome OS and lose all the software that doesn't exist out of Windows.
  • gr__or 9y ago
    I think for a lot of people it'd be an excellent idea to do just that.
    • ozarius 9y ago
      +1million
• themodelplumber 9y ago
  > modern CMS I'd change that to "enterprise CMS". Experienced sole proprietor web devs have often moved to lightweight, non-enterprise, non-feature-packed CMSes, this being one reason.
• snowwrestler 9y ago
  Most CMS security is basic stuff like file permissions (where Wordpress sites often get into trouble), applying community patches quickly (both Drupalgeddons), and managing JS library dependencies (a notable hole in the Drupal patching ecosystem). It takes some expertise to do these correctly, but it's not rocket science. I taught myself and have self-hosted Wordpress and Drupal sites for 8+ years with very few security incidents. That said, I'm moving my Wordpress and Drupal sites to platforms like WP Engine and Pantheon. But not because of security concerns--because the platforms will accelerate our development process by making it easier for developers to create staging instances and deploy to production.
• askvictor 9y ago
  Which leads to concentration of hosting to a handful of large enough providers (e.g. AWS, Google, Azure)? I completely get your point, but struggling to see a way forward here.