TiddlyServer 2.2 beta

Improvements

• Improvements to JSON schema for config file.
  • Suggested defaults for tree and option elements in arrays and objects. Press ctrl+space (or whatever your shortcut is) to see suggestions.
  • XML files should now work for the tree option. Still need to do testing on this one.
• Schema can be written to disk by running tiddlyserver gen-schema.
• New command line syntax and more commands. Use --help to display options.
• Published on NPM. Install globally and run using the tiddlyserver command.
• Uses the tiddlywiki-slim-* bundles for datafolders.

Bug fixes

• Files not uploading for external drives in some environments. Files will now be uploaded to the destination directory and then renamed.

TiddlyServer 2.2 alpha 8

This release is more code cleanup internally, drops some unused code, and now is published to NPM.

TiddlyWiki 5.1.22

This is technically an alpha version of TiddlyServer, but it's working fine for me and I expect it to work for you as well. Please open an issue if you run into any trouble and I will do my best to help.

There are two ways to install this.

The first is to run npm install -g tiddlyserver. This will install it as a command that you can run on your computer. You will need to specify the path to your settings.json file. Run tiddlyserver --config path/to/settings.json to start TiddlyServer.

The second way is the old method listed in the readme. The one change is the required files are included in this release as downloads. Unzip the tiddlyserver archive and name it whatever you want. Then create a node_modules folder in it, and unzip the tiddlywiki-production archive into that and rename the folder tiddlywiki-production.

Instead of creating a node_modules folder, you can also add "_datafoldertarget": "/path/to/tiddlywiki" to the settings.json file

Upgrade to TiddlyWiki 5.1.21

This release upgrades to TiddlyWiki 5.1.21. The bundle is copied directly from TiddlyWiki5-production, so it will have the same file structure for your version.

I've also added /assets/tiddlywiki/ to serve the tiddlywiki folder. It will server whatever folder is being used, so if _datafoldertarget is set, it will serve that folder. You can use this URL instead of the CDN URL described in TiddlyWiki5-production, since it is copied directly from that repo.

This is a more advanced solution than using $:/core/save/all-external-js. If you have many wikis in your TiddlyServer installation, they can all use the same files which will get cached in the browser and shared between folders.

TiddlyServer 2.1 is finally ready

TiddlyServer 2.1 is finally here. You might not see much difference on the surface, but underneath a lot has changed. A lot of the changes center around the server config and the tree specification, both of which have seriously improved. You still have to write JSON, but the error messages are quite a bit clearer, especially if you have valid JSON text, but an incorrect setting or property name.

The tree has been reworked to allow group and folder level customizations. We don't match the path on disk, but if you specify it in the tree you can customize the backup settings, specify which users can access the folder, and change the put saver settings for that part of the tree. We've also added index options for groups and folders, so you can customize the directory page.

The simple things are still there just like before.

• Serve and save single-file wikis. You can also disable this feature or restrict which users can use it.
• Serve and modify data folder wikis. Now with WebSocket support.
• Serve files and folders anywhere on disk and organize them into virtual folders (called groups).
• Did you know you can specify the path to a file directly in the tree? Any path can specify a file or folder, even as the root of the tree, but I don't know why you would serve one file.

The more advanced features include

• Cookie-based login, which replaces basic auth.
• Advanced routing tree customization, including access restrictions and index pages for groups.
• Flexible options to specify the IP addresses to bind to.
• Serving over HTTPS using the NodeJS HTTPS server implementation.

It's all in the docs, which now has a home. Check it out at https://arlen22.github.io/tiddlyserver/. They're definitely not comprehensive, so feel free to ask if you aren't sure about something.

A big thank you to every who has made suggestions and tested the betas. TiddlyServer may not be done yet, but it wouldn't be what it is without that feedback.

Fix TiddlyWiki path

This is an update to the beta release of TiddlyServer 2.1 https://github.com/Arlen22/TiddlyServer/releases/tag/v2.1.0-beta

TiddlyServer 2.1

This is the beta release of TiddlyServer 2.1 A lot of settings have been changed and tree documentation is not complete, but the Readme should get you up and running. The basic concept is still the same, but some additional features have been added and the ServerConfig has been updated to reflect that. Most of this is the result of lessons learned with 2.0 and some additional features which I personally found useful.

Upgrade to TiddlyWiki 5.1.17

Note: WebSockets support will be revisited in a future release.

This release mainly upgrades to 5.1.17. It also finishes implementing the websocket server handling for data folders.

If a page requests a path that is not a data folder, it will be stored in a separate hashmap of such paths. Paths may be arbitrary, but only the actual path part of the URL counts -- not the query part. Paths under a data folder (i.e. if a data folder is mounted at /wikis/notes/mynotes, a WS URL pointing to /wikis/notes/mynotes/random) will be handed off to the data folder TiddlyWiki server handler.

This allows plugins to use their own channels (subpaths) under the data folder path. Care should be taken to name the path appropriately. Using the plugin's name is recommended.

/wikis/notes/mynotes/plugins/arlen22/helloworldplugin/and/more/levels/if/you/want

And plugins should not use paths outside the datafolder. The best way to determine the URL to use is simply to take the page URL and add to it.

new WebSocket("ws://" + location.host + location.pathname + "/plugins/arlen22/helloworldplugin/etc")

There is no client-side WebSocket object in TiddlyWiki. I don't think we need one. Client-side code can handle that itself.

On the server-side, the ws-client-connect message is sent whenever a client connects, and includes the client, HTTP request, and data folder sub path the client requested. This allows plugin code to select which clients they want to handle based on the request and subpath.

There is a global listener that listens to all clients and sends ws-client-message events which contain the message and a reference to the client. Plugin code may check if the client is in its own list of clients to handle or examine the contents of the message to determine whether or not to handle it.

A ws-client-close message will be sent when a client is no longer used. Plugin code should then remove all references to the client to allow garbage collection.

This is assuming that pull request TiddlyWiki/TiddlyWiki5#3289 gets merged in. So the specification is complete and I've implemented TiddlyServer's part, but TiddlyWiki 5.1.17 does not yet contain all the code necessary for this to work. However, it is in the pull request, and will hopefully be there by 5.1.18. TiddlyServer itself only implements the ws-client-connect event and non-datafolder requests in order to avoid code duplication.

Plugins may take advantage of the websocket server by calling $tw.hooks.addHook('th-server-command-post-start', (simpleServer, eventEmitter, serverPlatform) => void);.

The simpleServer handles routing and contains the pathprefix (simpleServer.get("pathprefix") if desired). The eventEmitter emits the events I mentioned above, and may also be accessed at $tw.wss after the hook finishes. The serverPlatform is a string specifying which server is in use (currently tiddlyserver or tiddlywiki).

Use 2.0.14-fixed insead of 2.0.14

https://github.com/Arlen22/TiddlyServer/releases/tag/2.0.14-fixed

TiddlyWiki 5.1.16

Changelog

Breaking changes

• Added /static as a reserved mount path and moved /icons to /static/icons.
• Upgraded to TiddlyWiki 5.1.16

Improvements

• Added a warning if a mount path in settings.json is reserved.
• Added a settings page at /admin/settings/. The tree and types options are not yet available.
• Added allowLocalhost hashmap to settings.json identical to allowNetwork. Options for one of them does not affect options for the other one, so localhost can be more restricted than network.
• Added several options related to logging, and now allows logs to be saved to file using NodeJS appendFile.
• • Added options: logAccess, logError, logColorsToFile, logToConsoleAlso.
• Added debugLevel to set the debug level of the messages to be logged to console or the error log.
• Added filename field to specify the filename of the file being uploaded.