myWebLog
Installing
Get the Release
Releases are packaged for Windows and Linux; obtain the one you wish to set up and extract the archive. Within it, there will be:
- An executable file -
myWebLog.exe
on Windows,myWebLog
on Linux - Two
.zip
files (the admin and default themes) - An
appsettings.json
file - A platform-specific library for SQLite (
.dll
on Windows,.so
on Linux) - An empty
wwwroot/upload
folder
These should all be placed within the same directory; just extract the archive, optionally delete it, and your installation is ready for…
The Execution Environment
myWebLog needs an ASP.NET Core 6 capable web server and a data store; for the latter, there are four options. These are, in order of precedence:
- SQLite with a specific database
- RethinkDB
- PostgreSQL
- SQLite using a default database
SQLite (Low/No Configuration)
SQLite is a single-file, in-process database. myWebLog will look for the connection string SQLite
to use for its connection; if there is no connection there (and no other connection strings), it will default to using a SQLite database named myweblog.db
in the current directory. The application will create the database if it does not exist, so the server process will need read/write access to its location. When SQLite is being used, session data will be cached in a separate session.db
; to override this, provide a path (not connection string) as the SQLiteCachePath
connection string.
The example appsettings.Production.json
below contains the effective default settings; copy/pasting this into your configuration file will give you a starting point. (Remember, if you are fine with these, you will not need to create an appsettings.Production.json
file for data configuration.)
{ "ConnectionStrings": { "SQLite": "Data Source=./myweblog.db;Cache=Shared", "SQLiteCachePath": "./session.db" } }
RethinkDB
RethinkDB is a fast document database, and the data store which myWebLog originally supported. (Setting it up is a bit outside the scope of this document, but future versions of this page may have tips on how to do that.) This project uses a library that supports providing connection parameters via a URI. The example below uses RethinkDB on the localhost with the database myWebLog
:
{ "ConnectionStrings": { "RethinkDB": "rethinkdb://localhost/myWebLog" } }
The complete URI scheme is detailed here; when RethinkDB is being used, session data is cached in the Session
table on the existing connection.
PostgreSQL
(new in v2-rc2) PostgreSQL is, hands-down, the best open-source relational database. It is a great choice for myWebLog, and does not require the web server to have write access to a directory on your web server as SQLite does. To establish a PostgreSQL connection, provide a connection string in appsettings.Production.json
named PostgreSQL
. The example below connects to a local PostgreSQL server using a myweblog
database and user:
{ "ConnectionStrings": { "PostgreSQL": "Host=localhost;Database=myweblog;Username=myweblog;Password=[the-password]" } }
You will need to create the user and database; additionally, on first run and on upgrades, this user will need DDL permissions. Otherwise, read/write access will be sufficient.
Other Configuration
If you plan to store uploaded files on the filesystem, the web server process will need to be able to write to the wwwroot/upload
directory. There is also more information about configuring things like logging levels and what HTTP port myWebLog uses in the advanced configuration section.
The Executable File and Its CLI
myWebLog.exe
or myWebLog
are not just the process that you'll run to serve your sites; they also have a command-line interface to allow certain maintenance actions to be performed. These are detailed throughout the documentation, but you can run ./myWebLog help
for a quick list of all of them, and run ./myWebLog [command]
with no options for a description of each command's options.
Creating Your Blog
Speaking of the CLI, that is how to create a new blog. The command requires 4 pieces of info: the URL base, the title of the blog, an e-mail address for the administrative user, and a password for the administrative user.
./myWebLog init "https://yadda.example.com" "A Blog about Nothing" "seinfeld@example.com" "jerrys-password"
(If this is the first blog created for your database, you will see notices that tables are being created. This is normal - and good!)
Once the application is running, you can use the e-mail address and password to log on to your new blog.
Setting Up a Service
This is operating-system dependent; follow the standard procedures for creating a Windows service or a daemon on your chosen Linux distribution. (Future release versions may contain template files to use to assist with this.)
Upgrading from a Previous Release
In general, the steps to upgrade are:
- Stop the service (or however you are running it)
- Extract the new archive
- Either:
- Copy all files from the archive in your current directory, merging the
wwwroot
directory to preserve uploads; or… - Copy
appsettings.Production.json
,wwwroot
, any.db
,.db-shm
, and.db-wal
files, and any-theme.zip
files other thanadmin
ordefault
from your old directory to the new one, then point your service to the new directory
- Copy all files from the archive in your current directory, merging the
- Restart the service
If any upgrades require deviation from this pattern, that will be noted in the release announcement. Data structure and format upgrades will be migrated automatically unless otherwise noted.
Upgrading from v2 to v2.1
SQLite users, you will want to do a backup with the v2 executable, then do a restore into a fresh database with the v2.1 executable. Its data representation was changed to closely mirror the PostgreSQL representation. As with previous upgrades that required backup/restore, this will only preserve the most recent revision of pages and posts.
Upgrading from v2-rc2 to v2
For RethinkDB and SQLite, the steps above apply. For PostgreSQL, its internal data representation changed significantly; rather than attempt an in-place upgrade, a much simpler upgrade involves using the standard backup and restore processes built into the application.
- Back up each web log in the database, using the v2-rc2 executable.
- Update the application to v2.
- Drop all tables in the PostgreSQL database. These tables are created in the
public
schema; inpsql
,\d
will list all these tables. For each of those, useDROP TABLE [name] CASCADE;
. (You may also choose to drop and recreate the database; provided the user credentials are the same, this will work as well.) - Restore each web log, using the v2 executable.
Note that each page and post will only be left with their most current revision after this process completes. If prior revisions are desired, those should be backed up using PostgreSQL's backup methods prior to dropping the tables.
Upgrading from v2-rc1 to v2-rc2
The upgrade from Release Candidate (RC) 1 to 2 did bring some breaking changes.
- Password storage was upgraded; however, because the application only stores a one-way hash of the password, the upgrade cannot upgrade them. v2-rc2 provides the
set-password
CLI command, which can be used to set a password for a particular user on a given web log. Its format is
./myWebLog[.exe] set-password [url-base] [email-address] [password]
- For RethinkDB users, this upgrade has a few steps. v2-rc2 changed the internal representation of dates and times, and the versions stored by v2-rc1 are incompatible. Changing these programmatically would have required reconstructing nearly all of the documents; however, restoring a v2-rc1 backup using v2-rc2 accomplishes the same thing. So, to upgrade to v2-rc2, perform the following steps: (note that you will want to do this before setting passwords)
- Back up each web log via the CLI, using v2-rc1's executable
- Drop the database (or tables, if the database has other tables)
- Restore each web log via the CLI, using v2-rc2's executable