5 ms·

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),

by jaza 6y ago

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 probably a static site generator such as Hugo. If you insist on staying in database-driven CMS land, at least go with Django or Rails.

dannyw 6y ago
There is nothing wrong with Wordpress and the LAMP stack. It’s fine for many great use cases. It powers, and will continue to power many of the biggest sites in the world. Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.
- judge2020 6y ago
  The only problem not addressed is that the browser directly interfaces with code that has access to the database and host computer. A static site generator is leagues more secure since you can lock anything that touches the database/CMS content behind multiple layers of authentication and 2fa, significantly reducing the attack surface.
- sneak 6y ago
  The problem isn't LAMP, the problem is wordpress. It stores state that should be in files in the database, and state that should be in the database in files, so they are tightly coupled, and you have to snapshot both at the same time. It's also a security nightmare and runs dynamic code on every page load by default, so a fresh wordpress install in its default state will fall over when on HN on Reddit or Slashdot, unless you install third party caching plugins to avoid that. It's a bad app.
  - marc_io 6y ago
    It's clearly not “bad” for a lot of people, as it powers a huge portion of websites, everywhere.
    - sneak 6y ago
      The vast majority of those people contract out the (complicated) maintenance in keeping it secure and performant, or they get hacked and their site goes down, or they get ~no traffic so performance doesn't matter and neither does their choice of blog software. Entire large businesses (WPEngine, for example) have been built upon the overhead costs from blog operators having to compensate for it being a bad app. My close friend is one of the sysadmins for the WP instance mentioned in TFA. Pull back the curtain and it's pretty ugly and resource-intensive to run WP at scale; I've done it myself.
wvenable 6y ago
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.
- ozorOzora 6y ago
  IMO this is the single most relevant issue with static generators. Hopefully it will be adressed soon.
- ssijak 6y ago
  You just use a headless cms that have post scheduling. Like Prismic for example.
- jeromenerf 6y ago
  Hugo metadata allows to define a publication date for content. Then you need to run the Hugo build periodically to have the content published. The hugo cli has options to build "drafts" and "futures" so that you can preview them. I have used Hugo in the past to generate websites from external content sources, such as trello, gitlab, GitHub, RSS feeds, Dropbox, headless CMSes, etc. Some of them provided webhooks to trigger the build, others required polling and periodic rebuild, yet others can commit to a git repo and trigger a CI pipeline. Most of the time, hugo was more of a composable solution to a given flow than a constraint i had to build around thanks to its capabilities to use "data content" and not only markdown files. Using json as the metadata "front matter" for documents often proved very handy when using API sources. Hugo is very fast, so build time wasn’t a big concern. There was no incremental build however, so for a very large corpus it could be an issue. The most problematic issue is that Hugo doesn’t ever delete anything from a previous build, but overwrites on top, so that could be problematic if you involuntarily publish something and then want it off. The same kind of issues you get into with caching or object storage. My "solution" was the classic parallel builds, symlink and cleanup dance. Would recommend.
  - angulardragon03 6y ago
    Just wanted to add that I use Hugo in combination with a super simple CI/CD pipeline, and I just rsync the public/ directory every time the pipeline runs with the delete option enabled. This makes it relatively trivial to delete content after the fact, because I can just delete the content from the repository and have the pipeline remove it.
cutler 6y ago
Come off it. Much as I prefer Ruby and Python the CMS domain is dominated by PHP and ASP.Net. Whilst there are Rails and Django-based CMSes their combined adoption is a drop in the ocean compared with Drupal alone, never mind Wordpress.

by jaza 6y ago

dannyw 6y ago

There is nothing wrong with Wordpress and the LAMP stack. It’s fine for many great use cases. It powers, and will continue to power many of the biggest sites in the world. Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.

judge2020 6y ago
The only problem not addressed is that the browser directly interfaces with code that has access to the database and host computer. A static site generator is leagues more secure since you can lock anything that touches the database/CMS content behind multiple layers of authentication and 2fa, significantly reducing the attack surface.
sneak 6y ago
The problem isn't LAMP, the problem is wordpress. It stores state that should be in files in the database, and state that should be in the database in files, so they are tightly coupled, and you have to snapshot both at the same time. It's also a security nightmare and runs dynamic code on every page load by default, so a fresh wordpress install in its default state will fall over when on HN on Reddit or Slashdot, unless you install third party caching plugins to avoid that. It's a bad app.
- marc_io 6y ago
  It's clearly not “bad” for a lot of people, as it powers a huge portion of websites, everywhere.
  - sneak 6y ago
    The vast majority of those people contract out the (complicated) maintenance in keeping it secure and performant, or they get hacked and their site goes down, or they get ~no traffic so performance doesn't matter and neither does their choice of blog software. Entire large businesses (WPEngine, for example) have been built upon the overhead costs from blog operators having to compensate for it being a bad app. My close friend is one of the sysadmins for the WP instance mentioned in TFA. Pull back the curtain and it's pretty ugly and resource-intensive to run WP at scale; I've done it myself.

wvenable 6y ago

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.

ozorOzora 6y ago
IMO this is the single most relevant issue with static generators. Hopefully it will be adressed soon.
ssijak 6y ago
You just use a headless cms that have post scheduling. Like Prismic for example.
jeromenerf 6y ago
Hugo metadata allows to define a publication date for content. Then you need to run the Hugo build periodically to have the content published. The hugo cli has options to build "drafts" and "futures" so that you can preview them. I have used Hugo in the past to generate websites from external content sources, such as trello, gitlab, GitHub, RSS feeds, Dropbox, headless CMSes, etc. Some of them provided webhooks to trigger the build, others required polling and periodic rebuild, yet others can commit to a git repo and trigger a CI pipeline. Most of the time, hugo was more of a composable solution to a given flow than a constraint i had to build around thanks to its capabilities to use "data content" and not only markdown files. Using json as the metadata "front matter" for documents often proved very handy when using API sources. Hugo is very fast, so build time wasn’t a big concern. There was no incremental build however, so for a very large corpus it could be an issue. The most problematic issue is that Hugo doesn’t ever delete anything from a previous build, but overwrites on top, so that could be problematic if you involuntarily publish something and then want it off. The same kind of issues you get into with caching or object storage. My "solution" was the classic parallel builds, symlink and cleanup dance. Would recommend.
- angulardragon03 6y ago
  Just wanted to add that I use Hugo in combination with a super simple CI/CD pipeline, and I just rsync the public/ directory every time the pipeline runs with the delete option enabled. This makes it relatively trivial to delete content after the fact, because I can just delete the content from the repository and have the pipeline remove it.

cutler 6y ago

Come off it. Much as I prefer Ruby and Python the CMS domain is dominated by PHP and ASP.Net. Whilst there are Rails and Django-based CMSes their combined adoption is a drop in the ocean compared with Drupal alone, never mind Wordpress.