The scope of work to be done as part of this project is rather extensive. While the needed work has been tracked in Jira, for instance using epics for groups of related changes that are part of an overall feature, previous attempts at an overarching prioritization have been difficult to effectively execute on. This has caused disparities within the project, where some areas are very thoroughly-developed, and others have little to nothing added. The mere existence of such disparities is expected, for instance, in the presence of advanced features, but because some of these gaps extend to some basic areas…
Hello all! I thought I’d make a quick blog post to talk about one of the design decisions within Wikijump to maintain compatibility with existing Wikidot data: IDs. Like many other pieces of software, both Wikidot and Wikijump use numerical IDs to uniquely identify various data objects. To name a few, all users have an ID, as do all sites, all pages, all revisions within those pages, etc. The most common way to uniquely assign such IDs is to do so sequentially. You start with say 1, and then every time a new user is created you take the current…
A quick announcement, we recently moved to a new environment for dev! For brief background, we note three environments for where Wikijump can be deployed, local, which is any developer-run instance run off that computer, dev, which is like a staging environment, and prod, which will be the real production environment where actual data and users exist. Before this change, we provisionally deployed our dev environment in a permanent virtual machine with Dokku installed on it. Then, on merge to develop, a GitHub action would push the code and a new Dokku build would run. This worked, but had some…
Over the course of Wikijump development, both analyzing Wikidot code and implementing new Wikijump code, we’ve come across a fair number of table schemas. And there’s something we noticed, which is that there are a lot of database tables which essentially just link one thing to another, potentially tagging on some data. Now this is actually kind of a problem. Because, for each table, we need to have boilerplate for CRUD operations, as well as checks for sanity and permissions. This is a place where Wikidot definitely comes up short; user blocks only affect private messages, some systems for inputting…
It’s been a bit since the last development blog post, and as you can see from the post’s title, I meant to write this sooner. That said, things have generally proceeding gradually and smoothly. In this blog post I wanted to highlight one particular improvement made to DEEPWELL, our backend / internal API service. To first provide some context, within the current architecture, DEEPWELL is what stands in front of the various datastores (PostgreSQL, Redis, S3) to provide logical Wikijump operations. This means that it provides operations we think of when it comes to wikis, such as “edit this page”…
This was also mentioned in chat, but this post is to inform the community that as of October 25, 2023, I (aismallard) am now the official Project Lead for Wikijump, after a discussion with bluesoul. Apologies for the belated notification. This should not affect anything day-to-day within the project, and is simply intended to reflect the current reality of development. I highly appreciate bluesoul’s past and ongoing support of the project, particularly his expertise with AWS and his past work rigging up the ancient Wikidot code which sparked this project to start. His influence and assistance has been and continues…
Hello all, it’s been a bit. Sorry about that. This is aismallard, I’ll be speaking about my perspective and work on Wikijump. Where we are now, why that is, and where I’d like to go from here. Past Missteps First I think there are a number of items which, while obvious in hindsight, contributed to a lot of delays which could’ve been avoided. This project originally began because bluesoul was able to, using a combination of publicly available resources and help from former contributors, piece together a Wikidot.org build. For those unaware, this was a (discarded) project to have an…
It’s been another week, and here’s another weekly update. We’ve had 230 commits in 29 merged pull requests across 200 files, for a total of 6,036 line additions and 2,406 deletions. More work has gone into our new frontend, along with incremental improvement to our PHP codebase in anticipation. This week, we got several big steps in our frontend, such as getting login and registration views, support for toasts, and infrastructure for gestures on touchscreen platforms. As this is the point where we’re gluing things together, we’ve needed re-evaluate and fix up parts of our stack, which has been challenging…
This last week has been productive. We’ve seen some steady progress on the PHP backend, and massive strides in our move towards a new frontend. In the last week we’ve pushed 298 commits across 380 files, for a total of 5,802 additions and 5,849 deletions in 29 different merged pull requests. On the PHP end, things have been incremental but not groundshaking. In addition to some refactoring and legacy code pruning, the diff functionality was updated to be more readable. Compare: Instead of Wikidot’s unusual word-based difference view, the original lines added/removed are shown. Additionally, it uses the context information…
It’s been another busy week over here in Wikijump! We’ve merged 18 pull requests from 4 people, and added 217 commits over 1,171 files. Most of the work we’ve seen has fallen into one of two categories, Docker and PHP. So let’s start with our build process: We use Docker to build Wikijump. Local deployments use docker-compose to stand up all the component containers (currently php-fpm, nginx, postgres, memcached) and permit it to run locally. Several big changes were made to our build process, primarily a refactored php-fpm Docker build to be significantly sped up by taking better advantage of…