I would add this - there should be a clear distinction between the Open Source project and the Edgeryders version. The two are mostly the same, but there are some important differences:
-
The Edgeryders API behaves a little differently from a vanilla installation of Discourse. James built useful endpoints for fetching content - for example, for fetching topics. These endpoints should not (and are not) used in the Open Source project, as they will not work with any other Discourse installation.
-
The Edgeryders Webkit hosted at live.edgeryders.eu has a ‘multi-site’ configuration. This means one installation is the ‘backend’ for many sites - and these sites are routed through different domains or aliases (in our case defined here).
After the XML syntax, this is the second significant change made in the last few weeks.
The benefit of using a single installation means:
- Updates are deployed across all sites instantly
- We reduce overhead by only having one repository to maintain (versus many dozens, one for each site),
- We can easily use something like Netlify Analytics to get visitor stats from all the sites at once.
- The form component, which we are still trying to integrate with the platform, requires significant customisation on the Discourse end (this was done by Matthias, James and Hugi) - and so is not standard with the open source project for now.
The final point, being this:
I agree and that needs to be updated… I think the XML syntax serves project managers (and myself) better than the JSON syntax, it reads like HTML and is a lot closer to writing a post on Discourse, with the use of some additional tags.
The end result is still JSON, but that part is now behind the scenes and does not require a project manager to learn. It’s far easier to write this with fewer errors:
<Content>
<Text style="color: red">
Hello
</Text>
</Content>
Than this:
"blocks": {
"content": {
"text": "hello",
"style": {
"color": "red"
}
}
}
JSON is very picky with trailing commas, missing quotation marks or closing curly braces (and the more of them you have, the higher the risk of error). It’s an error prone format for what we are trying to do, which is easily deploy sites with minimal trouble.
So, this needs to be properly documented - probably here and will do it next.
Agree that themes are also very important, for the same reason as mentioned before: using a small set of CSS themes makes updating and improving the look of dozens sites a lot easier than updating one site at a time. At the moment we have two basic themes:
- The very simple default theme, used here: http://research.edgeryders.eu
- The magazine-like theme used for events, campaigns and newsletters, example here
Overall I’m happy with the direction the Webkit is taking and more comfortable with people using it in this form than the previous iteration…
In terms of project development, the main hurdles are (in reverse order of difficulty & time needed):
- Getting the form component to work with the platform (this has been very challenging)
- Parsing the XML tags for all the Views (slides, grids, lists, events…)
- A blog view for displaying topics
- Documentation:
- How to use the XML tags
- How to use a theme
- How to configure a form
- How to style individual elements
- How to set up an alias and domain