* Promote Gitter Chat in the Readme
I'm not sure if it's ok to use inline styles for a small addition like this... also, feel free to change the colors :-)
* Added link to Gitter in 'Forums' tiddler and transcluded it in the readme as per @Jermolene comments
* Fixed transclusion and built readme
* Modified Readme so the 'forums' section is transclued with lower heading levels
* add link to "How to" keyboard shortcuts + styles
* add "How to create keyboard shortcuts"
* Update How to create keyboard shortcuts.tid
* Update How to create keyboard shortcuts.tid
* Update How to create keyboard shortcuts.tid
* Documentation of Using Excise text
Documentation on the Excise text function.
I propose that the Excise text drop down ( the tiddler: $:/language/Buttons/Excise/Caption/Tag) links to this doc. I don't have permission to (or don't know how to) edit that tiddler in github.
I propose the following text for the drop-down tiddler:
Tag new tiddler with the title of this tiddler (If the title is changed you have to [[save and re-edit|Using Excise]] to use the new title as tag).
see the issue:
https://github.com/Jermolene/TiddlyWiki5/issues/2531
* Update Using Excise.tid
changed headings in response to discussion
* Doc for editor toolbar buttons (wikitext)
Documentation for buttons special to the editor toolbar (wikitext)
* Update Using Excise.tid
placed it under the new [[Editor toolbar]]
* Update Using Stamp.tid
placed it under the new [[Editor toolbar]] tiddler
* Update WikiText.tid
added reference to [[Editor toolbar]]
* Update Formatting text in TiddlyWiki.tid
added reference to the [[Editor toolbar]]
* Update WikiText.tid
* Update Editor toolbar.tid
* Update Editor toolbar.tid
* Update Editor toolbar.tid
* Update Editor toolbar.tid
typo
* Make modals display in source Window
this makes modals display within the window where they got opened, with the parameter `rootwindow` that, if `yes` or `true`, shows the modal always in the root TW window (`<$action-sendmessage $message="tm-modal" $param="mymodal" rootwindow="yes|true"/>`)
* pass the full event to $tw.modal.display
we need the event there to find `srcDocument` and `srcWindow`
* pass event in options object
* update modal.js to use options.event
* add docs for rootwindow tm-modal attribute
To avoid clashing with tiddlers called "login-basic" :)
We also need to revise the rout for /status for the same reason, but there are backward compatibility issues there
* Update Macro Definitions in WikiText.tid
*The table is intended as an overview.
*The "Parameters as Variables" example is more clean cut than previously.
Please note that the text lacks an example of direct `<<variable>>` invocation (because I'm not even sure I categorize or name this properly). Also my changes may contain factual errors or faulty lingo - please check!
* Update Macro Definitions in WikiText.tid
* Clarify the drag-n-drop behaviour
In my case I misunderstood it: I thought that I need to select the text and
drag the selection, because drag-n-drop did not work by default.
* Fix grammar
A few minor improvements that I propose are merged directly.
But, @pmario , we also need a clarifying example showing how to target a tiddler using *multiple* tags. So, under the examples there ought to be something like this:... BUT I fail to get this to work (syntax?):
```
[data-tags*="[[How to apply custom styles]] example-test"] {
outline: 2px solid green;
}
```
Further, the text states that
`Important: Tiddler tags are not sorted, so the order in the rendered output may be different!`
...but I'm not sure what this means. Does it mean:
```
Important: A tiddlers tags are displayed alphabetically but rendered styles may come out in a different order. As per standard CSS behaviour, styles rendered later override styles rendered earlier.
```
* Module-ize server routes and add static file support (#2510)
* Refactor server routes to modules
New module type: serverroute
Caveats: Loading order is not deterministic but this would only matter
if two route modules attempted to use the same path regexp (that would
be silly).
* Add static assets plugin
This plugin allows the node server to fetch static assets in the /assets
directory. I felt that this was a feature that goes above the core
functionality. That is why I added it as a plugin. with the modular
route extensions this was a breeze.
* Add serverroute description to ModuleTypes
* Coding standards tweaks
* Fix filename typo
* Move support for attachments from a plugin into the core
* Missing "else"
* Refactor server handling
* Introduce a new named parameter scheme for commands
* Move the SimpleServer class into it's own module
* Deprecate the --server command because of the unwieldy syntax
* Add a new --listen command using the new syntax
For example:
tiddlywiki mywiki --listen host:0.0.0.0 port:8090
* Add check for unknown parameters
* Add support for multiple basic authentication credentials in a CSV file
Beware: Passwords are stored in plain text. If that's a problem, use an authenticating proxy and the trusted header authentication approach.
* Refactor module locations
* Rename "serverroute" module type to "route"
* Remove support for verifying optional named command parameters
The idea was to be able to flag unknown parameter names, but requiring a command to pre-specify all the parameter names makes it harder for (say) the listen command to be extensible so that plugins can add new optional parameters that they handle. (This is particularly in the context of work in progress to encapsulate authenticators into their own modules).
* Refactor the two authenticators into separate modules and add support for authorization
* Correct mistaken path.join vs. path.resolve
See https://stackoverflow.com/a/39836259
* Docs for the named command parameters
I'd be grateful if anyone with sufficient Windows experience could confirm that the note about double quotes in "NamedCommandParameters" is correct.
* Be consistent about lower case parameter names
* Do the right thing when we have a username but no password
With a username parameter but no password parameter we'll attribute edits to that username, but not require authentication.
* Remove obsolete code
* Add support for requiring authentication without restricting the username
* Refactor authorization checks
* Return read_only status in /status response
* Fix two code typos
* Add basic support for detecting readonly status and avoiding write errors
We now have syncadaptors returning readonly status and avoid attempting to write to the server if it's going to fail
* Add readonly-styles
We hide editing-related buttons in read only mode
I've made this part of the tiddlyweb plugin but I think a case could be made for putting it into the core.
* Add custom request header as CSRF mitigation
By default we require the header X-Requested-With to be set to TiddlyWiki. Can be overriden by setting csrfdisable to "yes"
See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers
* Add support for HTTPS
* First pass at a route for serving rendered tiddlers
cc @Drakor
* Tweaks to the single tiddler static view
Adding a simple sidebar
* Switch to "dash" separated parameter names
* Typo
* Docs: Update ServerCommand and ListenCommand
* First pass at docs for the new web server stuff
Writing the docs is turning out to be quite an undertaking, much harder than writing the code!
* Get rid of extraneous paragraphs in static renderings
* Rejig anonymous user handling
Now we can support wikis that are read-only for anonymous access, but allow a user to login for read/write access.
* More docs
Slowly getting there...
* Static tiddler rendering: Fix HTML content in page title
* Docs updates
* Fix server command parameter names
Missed off 30ce7ea
* Docs: Missing quotes
* Avoid inadvertent dependency on Node.js > v9.6.0
The listenOptions parameter of the plain HTTP version of CreateServer was only introduced in v9.6.0
cc @Drakor @pmario
* Typo
