Hello noderfolk! Welcome to this month's root log. There's a lot to talk about, though much of it continues to be behind the scenes work to continue to modernize the website. We've made great progress on several fronts.
The first thing I want to talk about is the Everything2 Code of Conduct. It's posted as a writeup in the normal style of the Virgil E2Docs elements but we're thinking about moving that system to its own more prominent display type. At any rate, we're looking to codify acceptable behavior on the site, and is something we needed to have in place before we really start to scale again. Everything is a draft of course, and any feedback is good. We wanted to leave enough room for staff discretion without making it an exhaustive list of things people can and can't do. Another goal was to be as permissive in content as possible, though we are looking at content standards as well. Generally speaking we err on the side of free speech, but we understand how quickly a toe can go over the line to use that to harass other users. Creativity in communities is fostered when authors know that community leadership looks after them when they pour their heart into something. We can do more here, but this is a huge start.
On the technical side of the house, the new asset pipeline system is in and is working. You can't tell because the cutover was successful. If you use your browser developer tools, you can see most of the assets coming from deployed.everything2.com. All JavaScript and CSS assets are a part of the build system, which checks them for correctness, compiles them, and moves them over to the deployed asset bucket in a way that is tagged with the latest git commit from Github. As we continue to tighten up the deployment here, this has several implications for the user and coder communities here:
- Unsupported stylesheets have been deleted. There were about 70 or so unsupported stylesheets that were hanging around the system, with a few users here or there. I've messaged all users who have these alternate sheets and pushed them back over to Kernel Blue for the time being. This is going to allow us to keep a smaller number of options around until the new reactive design is ready. You have been credited for your contributions by username in the AUTHORS.md file and if you want your old CSS for any reason, it has been committed in git form to the repo.
- Authors can no longer edit their themes through the website. The website used to automatically upload a new version of the stylesheet to Amazon S3, and would keep a contentversion tag associated with it. This is all fine and good, but it also meant that the owner of a stylesheet could break something and we'd never know. Over the last few weeks, we've broken the link between the source and the publishing mechanism. Any further changes will no longer be represented and the canonical source is now the www/css directory in Github. If you'd like to make any change, please issue a PR and I'll approve and push it in. Over the next few weeks we'll be paring back the extraneous CSS management features here, which will largely be invisible.
So what's next? The priority remains Google search visibility so there are some areas where we need to push ahead. The first is in Javascript cleanliness. A lot of the site is tied into layouts that are tightly coupled with the jquery selectors that make it all kind of work. Now that the site tests and deploys as one cohesive unit, I can make changes to CSS/site code/javascript in one push. This means that I can make more invasive changes without wondering the side effects.
The goal for June is to get everything into a single, well-understood Javascript file, update jQuery (it's currently 8 years old), and get a test React pipeline together. React is going to allow us to use the standard webpack tools to have a rich and performant site experience which works well on mobile
Lastly we need to remove all inline javascript. In the beginning, E2 would allow you to submit all kinds of things in all kinds of ways. We know now that it is a massive security liability. While we have all kinds of javascript and XSS issues, using some of the browser-based XSS protections will help. To do that we need to make sure that the Javascript sprinkled around the site is managed by the asset pipelines.
Back to the code mines!
-Jay