* In the interests of performance and expressiveness, switched to using a Sax parser instead of a DOM implementation.
* Use extensible declarative rules to control the slicing process
* Added new optional set of rules for slicing by heading, where the paragraphs underneath a heading are packed into the same tiddler as the heading
* Added a modal dialogue for specifying parameters when slicing in the browser
This plugin provides support for importing tiddlers as external attachments -- it only works on platforms such as TiddlyDesktop that provide the required "path" property with imported files.
Using the plugin means that instead of importing binary files as self-contained tiddlers, they are imported as "skinny" tiddlers that reference the original file via the ''_canonical_uri'' field. This reduces the size of the wiki and thus improves performance. However, it does mean that the wiki is no longer fully self-contained
Instead of the simple ‘prefix’ and ‘extension’ parameters, we now
accept a filename filter. As well as allowing prefixes and suffixes to
be added via filter operators, we can also transform the title
Tools for working with Amazon Web Services:
* Templates for saving a TiddlyWiki as a single JavaScript file in a
ZIP file that can be executed as an AWS Lambda function. In this form,
TiddlyWiki is a self contained single file containing both code and
data, just like the standalone HTML file configuration
* Commands that can be used to interact with AWS services, under both
the Node.js and Lambda configurations of TiddlyWiki
We now use highlight.js in raw HTML mode on the server, rather than
trying to use it with the fakedom. This causes problems with fakedoms
inability to get textContent for a node that has been created by
assigning innerHTML. So we extend the fakedom to allow the original
text content to be saved.
See #2778 for discussion.
The code here had got a bit broken by some PRs that I should have
checked more carefully. I’ve done a major refactoring which will
hopefully make it easier to understand, and fixes a number of problems:
* Problem with eg .md tiddlers not being deleted correctly
* Problem with Windows path separators not being usable within
$:/config/FileSystemPaths on Windows
* Problem with filename clashes not being detected correctly when
saving to a different directory via $:/config/FileSystemPaths
* Enables slashes within tiddler titles to be mapped into folders
* Enables plain text files like .md and .css to be saved with .meta
files instead of as .tid files (see #2558)
* No longer replaces spaces with underscores
As this is such a major update, I’d be grateful if Node.js users could
give it a careful run through — in particular, you’ll need to try
creating new tiddlers of various types and ensure that the expected
files are created.
See the readme:
“This plugin causes TiddlyWiki to continuously save the contents of
each tiddler that is changed as a JSON file. Configured correctly, the
browser will download the files silently in the background, and they
can be used as a backup in case of accidental data loss.”
Inspired by @telmiger’s comment (3) here:
https://github.com/Jermolene/TiddlyWiki5/issues/2741#issuecomment-276128
871
* trying to implement new googleanalytics tracker
* trying to put new google tracker. Not working...
* more dev options for testing
still don"t understand wants goes wrong
* New version. Seems to work
* achieved update for new tests
brought back tiddlywiki.com settings value
created a settings tab to make it easier
* adding settings to plugin
add a settings tab to plugin to make it easier to use and see which GA account is in use
* fixes bug with GA_ACCOUNT and GA_DOMAIN tiddlers containing newlines at their end, preventing plugins to work
* soft rebase on jermolene's master
* revert to oldest version of GA_account and GA_domain tiddlers - had been overwritten by ones with a new line at the end
* Integrates some @tobibeer comments
* googleanalytics.js : removed "rebranding", var declaration and console log. Did not manage to get a non-minified version of Google script. But as far as I can see, jermolene's original plugin did same way
* plugin.info : placed "readme" first
* readme : back to previous "legacy" version. No more mention to temporary fork. Added mention and link to google official code.
* signed CLA
Add support for skipping an entire tiddler if a particular column is
blank
Add support for reading a row by column, making each of the columns
into a fieldname.
Also significantly refactored the code to break up the main, monolithic
function.
Hi @welford I wondered if you could kindly review this commit, since
you authored the original code? Before this commit, I was running into
a crash when running `prerelease-bld.sh` from
`build.jermolene.github.io`, caused by using raw HTML for the
highlighted block. Switching to the fake dom seems to fix things, but
I’d like a second pair of eyes.
TiddlyWiki passes the MIME type of the tiddler to highlight.js as the
"language brush", but it turns out that highlight.js doesn't actually
understand MIME types. This commit introduces a configuration mapping
between common MIME types and highlight.js language brushes
Fixes#2535
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.
