We were using `String.prototype.replace()` without addressing the
wrinkle that dollar signs in the replacement string have special
handling. This caused problems in situations where the replacement
string is derived from user input and contains dollar signs.
Fixes#2517
Fixes#2503
This bug was introduced in commit c4c7b18 where it would append
additional .tid extensions to a file every time the node server was
restarted.
Here we check the filepath does not have the extension already before
appending it.
The plan had been to switch template depending on the content type, but
we’d only implemented support for saving wikitext tiddlers. That meant
that creating a tiddler with any non-wikitext content type failed to
write the file correctly under Node.js.
Now we just always save in .tid file format.
* Save binary tiddlers with meta file
The filesystemadaptor plugin was a little simplistic in its
understanding of a binary file. It was using the typeInfo dictionary to
choose what tiddler types were binary (and hence needed a meta file when
saving).
I looked as if it was trying to be smart by looking for the hasMetaFile
*OR* had the encoding of base64. Unfortunately the typeInfo only defined
image/jpeg and so any other base64 encoded tiddler was assumed to be of
type text/vnd.tiddlywiki.
The net effect was only JPG images got a meta file and everything else
were saved as .tid files with base64 encoding. It all still worked but
made working with binary data in a Git repo a bit daunting.
There is enough information in the $tw.config.contentTypeInfo to
determine if a tiddler type is encoded with base64 or not. A better list
is available from boot/boot.js who registers all the types thorough the
registerFileType and marks then with base64 were appropriate.
This commit uses the typeInfo dictionary first for any filesystem
specific overrides, then the contentTypeInfo, and finally defaults to
the typeInfo["text/vnd.tiddlywiki"]. It also eliminates the now
unnecessary override for image/jpeg.
I think this might have been the original intent from commit 10b192e7.
From my limited testing all files described in boot/boot.js (lines
1832-1856) with an encoding of base64 now save as the original binary
and a meta file. Meaning that when you start the node server and then
drag-n-drop a binary file (i.e. image/png) it will PUT to the server
and then save it on the filesystem as-is allowing the file to be managed
as a binary file and not a text file. (Binary diffs are better and
GitHub supports them as well).
* Prevent duplicate file extensions
A side effects of using the $tw.config.contentFileInfo in the previous
commit is that it will always append a file extension to the tiddler
title when saving. In most cases this is the correct course of action.
However, sometimes that title is already a proper filename with an
extension (for example importing 'foobar.png' would save a file named
'foobar.png.png') which seemed silly.
This commit simply checks to make sure the title does not already end
with the file extension before appending it to the filename. A little
convenience really.
Since IE apparently doesn't have the String endsWith method I took the
liberty to add a helper method to $tw.utils trying to follow the other
polyfill patterns. I figured this was more generic and readable then
attempting to use a one-off solution inline. I got the polyfill code
from MDN.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/endsWith#Polyfill
Is strEndsWith the best method name?
When saving new tiddlers on node.js, allow the user to override the path of the
generated .tid file. This is done by creating a tiddler
$:/config/FileSystemPaths which contains one or more filter expressions, one
per line. These filters are applied in turn to the tiddler to be saved, and
the first output produced is taken as a logical path relative to the wiki's
tiddlers directory. Any occurences of "/" in the logical path are replaced with
the platform's path separator, the extension ".tid" is appended, illegal
characters are replaced by "_" and the path is disambiguated (if necessary) in
order to arrive at the final tiddler file path. If none of the filters matches,
or the configuration tiddler does not exist, fall back to the previous file
naming scheme (i.e. replacing "/" by "_").
This implies we will now, for tiddlers matching the user-specified filters,
create directory trees below the tiddlers directory. In order to avoid
cluttering it with empty directory trees when renaming or removing tiddlers, any
directories that become empty by deleting a tiddler file are removed
(recursively).
Benefits of this configuration option include the ability to organize git
repositories of TiddlyWikis running on node.js, ability to replace characters
that cause trouble with particular operating systems or workflows (e.g. '$' on
unix) and the ability to replicate tiddler "paths" in the filesystem (by
including a filter like "[!has[draft.of]]") without forcing such a (potentially
problematic) change on all users.
* Add icon for view template segment
* Muted background colour for view template segment
* Include links to parent tiddlers in the view template segment
* Fix logic for hiding/showing documents/headings (“open”/“close” were
transposed)
Without modified dates, new imports do not appear in recent file list. The equivalent of modified dates in ENEX is the 'updated' tag, with a date format similar to that of TW with the exception that the date format consists of a date stamp, a letter T, and a time stamp followed by Z for UTC presumably. There is no millisecond indicator. Not all ENEX notes have an update tag. The solution here is to apply creation date by default and then apply the update date if it is available. Dates are converted by stripping out Z and T and appending '000'.
@sukima the main issue with the previous code was that it incorrectly
used comma to delimit tags. We actually use spaces, and double square
brackets to delimit tags containing spaces. Better is to leave the tags
field as an array; the core will serialise it correctly as required.
I also made some minor consistency tweaks.
Relates to Issue #2268
I tried to map over the list of tags but NodeLists are not arrays and so
need to be converted. This looks ugly and probably should be abstracted
to a function. Come to think of it should we have a `$tw.utils.map()`
function?
Relates to Issue #2268
Based in the [example XML][1] attachments are listed in the <resources>
node. Since in TiddlyWiki these would be media tiddlers I add then one
by one as separate tiddlers.
There are some things that still need to happen. There should be a mime
type check so we don't attempt to import media tha TiddlyWiki doesn't
support. Also the example suggests the data is base64 encoded so I
blindly use that for the text attribute. Should there be a
`data:mediatyp;base64,…` prefix?
[1]: https://gist.github.com/evernotegists/6116886
Integrating this module allows us to do HTML/XML parsing under Node.js
(there is no built-in support for Node.js; we can already do HTML/XML
parsing in the browser). The implementation chosen is pure JavaScript,
and will work in all configurations of TiddlyWiki.
The immediate motivation is the work I’m doing to integrate with Amazon
Web Services.
We should be able to use JSZip to export multiple tiddlers in a single
operation from the browser.
Instead of showing a sequence of all documents in the preview column,
we just show a single document, with a dropdown to choose which one is
shown.
The change makes it easier to deal with large numbers of documents.
The metadata for each field is in a tiddler tagged
`$:/tags/DocumentMetaData` with the field `caption` being the displayed
caption for the field and `field` being the name of the field.
`field-type` is the type of the field, and can be “string” or “list”.
Previously, newly created image files would end up being saved as a
base64-encoded .tid file. Now they are saved as an ordinary binary file
with an accompanying .meta file for the metadata.
By making the docs available as a plugin we make it easier for people
to fork their own copy of the docs without losing the ability to get
updates in the future (which can be done just be updating the docs
plugin)
Many reasons:
* to allow subtrees to be grafted more easily
* to keep the tags for an entry clean by removing structural tags and
leaving the semantic tags
* to avoid the duplication of expressing the same relationship through
both the tags and list fields
1. Switch from using the text field of lists for storing the associated
filter to using the field `toc-list-filter` (to make it harder to
accidentally parse the text of an ordinary tiddler as a filter)
2. Fix several bugs
The exclude filter `+[tag[intro]]` will produce a document that only
includes the paragraphs with the tag “intro”. These are derived from
the paragraphs in the original document with the CSS class “intro”.
