* core/templates/external-js/tiddlywiki5-external-js.html.tid,
core/templates/external-js/save-all-external-js.tid,
core/templates/external-js/save-offline-external-js.tid
core/templates/external-js/load-external-js.tid:
Fix#5343. Exclude client-server plugins in tiddler imports and to
specify a working URL for loading tiddlywiki5.js from local disk.
Mirror save/all and save/offline templates in the regular server
edition.
Fix#4717 (tiddlywiki5-external-js.html.tid)
* core/modules/saver-handler.js:
Need the change to make single file autosave work with the external-js
template.
* editions/server-external-js/tiddlywiki.info:
Provide external-js related build targets.
* core/language/en-GB/Snippets/ExtJSReadme.tid:
Temporary doc to supplement TW5.com's external-js section. Demonstrate
that upgrade could be done on single-file wikis with an externalized
TW core.
* core/language/en-GB/Snippets/GetTiddlyWikiJS.tid:
Documentation. Meant to be included in every wiki and to help end
users acquire tiddlywiki5.js.
* The "tip" macro isn't designed to be used in a table cell (it generates a blockquote)
* We avoid full stops at the end of table entries or list items
It seems to be incredibly hard to police consistency with documentation but I think it's very important
@pmario we avoid using the details element because it doesn't remember its state across refreshes. It's not something that we should encourage people to use if they don't understand the limitations.
I also simplified the radio widget example because putting all the options on one line with a vertical bar separator is not a common way to display radio buttons.
We can now pass arrays of rule classes to the parser constructor, overriding the rules that would normally be used by the parser.
This allows us to create custom variants of the wikitext parser with their own content type.
It could also provide a basis for a new Markdown parser based on our existing wikitext parser but with new rules.
The default behaviour is unchanged, but if you write "yes" to
$:/UploadWithUrlOnly then it will assume it's possible to upload
with a blank username and password, as long as the host is set.
The motivation is to support a upload plugin compatible upload
service that uses some method to authenticate other than the legacy
upload plugin user/password params.
Without this patch, the user would need to enter something random in
the user and password fields for TW to decide the upload plugin can
be used.
