Platform for the site

[davidfischer]

Even having just a publisher and advertiser page, it's pretty clear we need something more than HTML files to run the site. Since these are purely landing pages, I actually would prefer that they are stored in a separate repository from the main ad-server repo. Otherwise we're going to run into similar issues we have with RTD where we want the code to be open but we don't want anyone to use our logos and trademarks.

While this is just marketing landing pages, there's a few things that would be nice:

• Templates: This could come in the form of Django templates or even just server-side includes or a static HTML builder. We want to re-use HTML for headers, footers, and more.
• Form handling: Currently we're farming out to Google forms. It isn't short term critical but having an embedded form will likely result in higher conversions. We could embed something like TypeForm or Google Forms itself or we could do our own form handling. We just need to send it somewhere.

I see a few solutions:

• Run a tiny Django/Flask site. It may not even need a DB. Hosting this is tricky since we do have to run it somewhere, but at least we all are familiar with how it would work.
• Run a static site builder like Jekyll. It won't handle forms since it's still pure HTML output but you can have templated pages fairly easily. I know Jekyll moderately well and I've used the Python equivalent (which isn't as good, IMO), Pelican.
• Deploy a proper CMS like Wordpress or Wagtail. That's probably overkill.

[agjohnson]

Any reason not to host this with the existing ads application? I'm a bit torn on this topic -- example, on the RTD site, having something like dashboard.readthedocs.com be our RTD instance, and readthedocs.com be a separate static site does have some strong benefits for authoring content. However, the downsides are fairly strong too -- 2 sets of templates to manage, 2 tools to manage, there is bound to be duplication of effort managing two sites worth of styles/etc, and the team would have to learn/get used to jekyll/pelican/flask/etc to contribute.

So, I think keeping it Django and perhaps even just rolling it into the existing application produces the smallest amount of overhead for the team -- it reduces friction by keeping everything similar. If there are any disadvantages to running both sites on the same instance, perhaps a small django application is the best.

I don't think we need a CMS, we're comfortable working with these templates already and use Git for versioning already.

[davidfischer]

Any reason not to host this with the existing ads application?

My biggest issue with this is that there are downsides and complications to a multi-domain application (eg. ethicalads.io for landing pages and server.ethicalads.io for the app). Django does not handle this particularly well IMO and there are complications with managing security (eg. HSTS, redirects, canonicalization) across multiple domains. We have this on RTD itself. Testing a multi-domain application is difficult as well.

I'm fine with a stripped down Django app if that alleviates concerns.

[ericholscher]

I'd also be fine with sphinx or mkdocs on RTD -- that is probably the easiest option.

[davidfischer]

I'd also be fine with sphinx or mkdocs on RTD -- that is probably the easiest option.

The implications of this is that there would be no form handling and we'd either have to build out a custom theme or use/customize something off the shelf. It does solve the templating issue.

[ericholscher]

I'd also be fine with a pre-compile jinja step or something, that might actually be the most simple.

[davidfischer]

I'd also be fine with a pre-compile jinja step or something, that might actually be the most simple.

That's effectively what Pelican or Jekyll are.

[ericholscher]

The nice thing about doing it through Sphinx is that we can build a small blog on the site using our existing blog setup with ablog. I think it probably makes sense to just use Sphinx for familiarity.

I did a quick 5 minute hack to show it isn't hard #19

[agjohnson]

Yeah, Sphinx is another option. I'm :+1: on using something inside our ecosystem already. It will introduce the least friction to authoring. Sphinx is malleable and we can customize it heavily if needed. I'm happy to help in this part.

For form handling, consider using Front directly using the form inbox method. The output might not be as nice, but it would go to a singular tool. I remember testing the form inbox and wasn't super impressed though, so I'm not a huge proponent of this.

[agjohnson]

Also, noted more here on the closed issue #19: https://github.com/readthedocs/ethicalads.io/pull/19#issuecomment-655685843