[tylersgordon]

Anyone know if this is the right tool for what we are trying to accomplish?

We are creating a CSV of thousands of food and allergy-related items, and want to automate the creation an independent post for each item. We can use another type of input instead of a CSV, as long as we can do it in bulk.

We want to have these pages to be SEO optimized for easy discovery on Google.

We could use wordpress with a mass importer, but it has a lot of bulk. These file-based CMSs look interesting.

[tomatsu]

> We can use another type of input instead of a CSV

Popular static website generators like Jekyll can generate pages from YAML files. Jekyll even supports CSV directly.

https://jekyllrb.com/docs/datafiles/

https://jekyllrb.com/docs/collections/#step3

[ioddly]

I can second this. I've built an index of scientific papers before with Jekyll's data feature. Built remarkably fast even with a lot of loops over the whole dataset.

[richthegeek]

Wordpress isn't bulky because it runs on a database, although you might say that running it with a database in the backend does allow it to be bulky...

The storage medium isn't really what you should be choosing your CMS on, I think. And depending on your required features and expected traffic volumes, I'm not sure there's much need to choose something else.

Sure, other CMS will serve pages faster and handle more visitors better natively... but WP can get you cheap devs fast, rather than casting around for niche workers.

[cies]

> but WP can get you cheap devs fast

Beware that you get what you pay for. If you need a high-traffic capable product with lots of modern web stack in (like React and some WebSocket thingies) and you plan to choose a fresh stack then going with WP might just be total productivity killer on the project.

WP is not a place to build your custom stuff on top of. I worked on several projects where we used WP headless, as an admin interface (since web master teams love it), but relinquish all the template rendering to an app framework (Rails in our case). We open sourced the infrastructure of it[1].

Not that Rails is so fast, but we knew it well and caching/ integrations with APIs/ ElasticSearch are all quite straight forward in Rails.

1: https://github.com/wponrails/wp-connector

[zapt02]

This smells of NIH to me. You built a presentation layer for WP in Ruby because that's what you are comfortable with. There's nothing wrong with that, but don't pretend that you are building anything other than (possibly) useless middleware. If you wanted a fresh stack with WP, you would use the WP API, Vue or React coupled with any caching software (Nginx, Varnish).

[cies]

> fresh stack with WP, you would use the WP API, Vue or React coupled with any caching software (Nginx, Varnish)

Has been considered.

But there where many integrations that were required, and they are simply too simple in Ruby land. Also we needed to take traffic --yet serve dynamic pages-- and support user logins. The solution I mention does use WP-API, but on top of that it also allows "previews" and the "admin bar" (would be quite interesting to implement those with React).

edit: That we had a lot of Rails expertise in house did help, as mentioned. We also do plenty React, but a lot of the integrations needed to be server-side and many were batch-processes.

[lkhkjhuiguguuy]

it sounds like what you're looking for is a "static site generator"

you can even run some of them against a git repo, so when someone checks in a csv change, it triggers a rebuild and republish