Hi Peter,

I really want to use this, but there are still problems. Sorry... :-(

I'll try to explain what and why below. Hopefully this is useful and we can move forward - I'd like to drop wok asap.

Simplicity first! Don't assume technical competence!

I hope a large number of our contributors won't be technical, so it's essential that simplicity wins. I want to be able to say to them: "If you put a file in content/foo.md you'll be able to see it served from the /foo endpoint. If you want a default page for a directory, just call it index.html or index.md, just like how every web server in existence works, so content/foo/index.html will also be found at the /foo endpoint whereas content/foo/bar.md will be at the /foo/bar endpoint".

For this to work, the content directory must map 1-1 to the structure of the output directory as I describe above otherwise it's confusing as hell for non-technical people. We mustn't expect any contributor to have to play with the urls.py or views.py code either.

This is important for another reason, if we find we have lots of international pages the global root shouldn't default to whatever is in /en/. I want to have an index.html in the content folder that'll act as global root.

If I navigate to /en/ I get a Django 404 page! I wasn't expecting that. The de content isn't even built.

I realise why (you're following links from /) but what if I want to develop a bunch of stuff and NOT have it linked from /..? This is another example of requiring technical competence to work out what's going on. I'd argue that the content of the content folder is the source of what should be rendered NOT the link tree scraped from the links found on /.

What happens if I want to serve a static file that's not .html or .md from a non-static path? (I've not tried it). I can imagine, for example, /examples/tutorial1/source.py type endpoints on the site.

Also, can we clean up the Django related stuff after a build - db.sqlite etc..? It just feels untidy having them hang around.

What I want is something very simple like the moon on the stick I describe above. ;-)

Amber is almost there, soooooo close, but not quite. Can this be fixed? I would offer to help fix things up but I have to write content, re-code a web-editor, fix some CSS problems, blah blah blah for Monday.

Hi @ntoll, thanks for the feedback. This is only the third site that I've used amber for (the other two aren't live yet) and it's good to get more input on how it could/should work.

Let's sort this out into issues with amber, and issues with how amber is set up for this site.

For this site:

• The content directory should map 1-1 to the output directory. I'm not sure, off the top of my head, whether amber can do this without any changes -- there's probably going to be some path munging problems, but it should be fixable.
• When development server is running, navigating to /en/ gives a 404. If we set up 1-1 mapping between content and output, this will be fixed by putting an index.whatever in /content/en/.
• I don't understand the question about non-static paths. Is this just to do with file extensions?

For amber:

• We should be able to build pages that aren't linked to anywhere from the root page.
• We should clean up db.sqlite after building the site.

Have I missed anything?

+100000 on all that!

Clarification - yes, non-static paths is just a question of files that should be served in their raw form no matter the file extension .

Yay!

I've updated amber to allow 1-1 mapping between content and output. (To do this, I had to allow for keys to contain slashes.) Before I rebase this branch against master and address the other concerns, can you check that you're happy with how it works?

Hi @inglesp,

Many apologies for not responding sooner. This looks great but I have a couple of queries:

• I'd like to explicitly state what template to use from inside the content files. From looking at the files you've put in there, I can't see how to do this.
• I want the root of the site (i.e. /content/en.html) to be called index.html ~ to follow the naming conventions used by web servers. It's important that we don't have a default root name that references one locale (en in this case) over others in its name. For example, I can imagine this page may contain more than just English content!

Hope this makes sense!
If you can address the above please rebase with master and I'll merge.

Many thanks for all your efforts with this! N.

I'm not realistically going to get to this before PyCon UK, sorry!