Blog capabilities of TiddlyWiki

[Herb Nazhe]

Hi everyone,
I am a new user of TiddlyWiki and I would like to know if the blog functionality of TiddlyWiki may optionally allow the creation of multiple TiddlyWiki files. I know, this is contrary to the one-file concept upon which TiddlyWiki is founded, but I think that there may be major benefits in implementing this as an option (if it has not been implemented already). The use case I have in mind is that of a proper blog, published on the web. I was thinking that in this case it would be extremely unwieldy to have all the media files included within one file. A (still vague) idea occurred to me, which is a hybrid approach actually: could we possibly have TiddlyWiki manage a blog by including only the text contents within the TiddlyWiki file, and using external links for loading the images? This way a user visiting the website won't have to download a massive file containing all the bulky media related to the blog webpages. Has this already been tried? If so, could you please provide some examples/links? I am very interested in this.

Keep up the good work with this AWESOME project! My heartfelt thanks to Jeremy and everyone else. I really appreciate the effort you have been putting into this wonderful piece of software.

Cheers,

--Dufriz

[Herb Nazhe]

As an addition to my previous post: when I said "the creation of multiple files" what I had in mind was the possibility of breaking down the TiddlyWiki file into several inter-related sub-files, each one for a major section of the blog (in case the blog has a very articulated and complex structure). This is, again, in the interest of keeping the size of the files smaller, because they have to be downloaded over the internet. Naturally, the interaction and coordination between the different files containing the blog sections should be managed automatically by the main TiddlyWiki file, without the end-user having to worry at all about this.
Cheers.

[RichardWilliamSmith]

Hi Herb,

Tiddlywiki can be used to generate a static website where each page is in its own file. This is advantageous for the reasons you state and several others. There are basic instructions available http://tiddlywiki.com/static/Generating%2520Static%2520Sites%2520with%2520TiddlyWiki.html but I am in the middle of preparing a more detailed tutorial so, if you're interested, watch this space.

Regards,

Richard

[RichardWilliamSmith]

I should add that the issue of 'externalising' images to reduce the page size is a separate, but related issue, and there are pretty good solutions for managing that too.

[TonyM]

Richard,

TiddlyWiki seems quite capable of displaying external media but it seems to me a second class citizen compared to drag drop and import. Have you heard of a mechanism to  Drag and Drop but only create external links? Allowing a relative link such as .\images would allow the tiddlywiki to be moved with its media to a host.

I would also like to do this with Hyperlinks or tiddler plugin sources, drag and drop the link only, not the content.

Just thinking

Tony

[TonyM]

Additional thought,

On the Import page that appears after drag and drop allow a button to import external links only. Create tiddlers with the external links.

Just dreaming

Tony

[Herb Nazhe]

On Saturday, 12 August 2017 01:48:54 UTC+3, RichardWilliamSmith wrote:

Tiddlywiki can be used to generate a static website where each page is in its own file.

Excellent. One questions: can the files be generated directly on the remote server (by a remotely located Tiddly generator)? Or will we have to create them locally and then FTP them up?

 

[Herb Nazhe]

On Saturday, 12 August 2017 03:13:45 UTC+3, TonyM wrote:

Have you heard of a mechanism to  Drag and Drop but only create external links? Allowing a relative link such as .\images would allow the tiddlywiki to be moved with its media to a host.

That is what I was hoping for. Any implementations yet/soon-to-come?

[Jeremy Ruston]

Hi Tony

> Drag and Drop but only create external links? Allowing a relative link such as .\images would allow the tiddlywiki to be moved with its media to a host.

That trouble is that browsers do not reveal to JS code the original path of the dragged file. We only get the file name portion. Browsers do this for security reasons, and there’s no workaround.

Best wishes

Jeremy

[RichardWilliamSmith]

Hi Tony, 

I built an interface that lets you externalise content. The use case primarily imagined is of accruing content over time (mostly images) and then periodically purging it to an external location. The tool then lets you redefine the 'root' path to the image folder, in the canonical uri field of every image tiddler, at once. This means that you can develop with your images in a folder locally (probably served from a simple server) and then easily switch to a matching set "in the cloud" as long as the relative position of all the files is the same.

On Saturday, August 12, 2017 at 10:13:45 AM UTC+10, TonyM wrote:

[RichardWilliamSmith]

Hi Herb,

Oddly, this is exactly the aspect to which I now turn my attention. There are two methods to be compared - the first is to build the static site and deploy the output. The second is to deploy the raw content and then run the build tool "in the cloud" using a 'continuous integration' method.

Either way the deploy tool du jour is 'git'; primarily a version control system that mirrors our changing content to a 'repository' at, for example, github.com. We 'push' changes to this online repo when we want to update our site. In the first scenario, our pushed code is the output and we're done. In the second, we require a further build step to be carried out. This is achieved via what is called a 'git hook' that will run a tool to build the output and deploy it as instructed.

Travis CI is one such continuous integration tool and it should be possible to set it up to run tiddlywiki and build the site but my preferred host is Netlify.com and I think their integrated tools ought to be able to do the same thing. Too many options, as always.

Anyway, you'll have a tutorial within a week, I promise.

Richard

[Mark S.]

But what if the dropped link was from an external web source? Does the browser still hide the address? Shouldn't it be able to access that url? And if the base url was the same for your TW and the dropped object, wouldn't it be possible to construct the relative path ? I'm thinking that in the context of Arlen's tiddlyserver you might be able to create the appropriate canonical uri tiddler with a portable relative address.

Thanks!

[@TiddlyTweeter]

OBSERVATION 1 -- Easier translation/conversion to portability--of absolute paths to relative--could be a godsend for TW.

For at least 2 reasons. First, universalism of platform (offline / online). Second, emerging issue if you want to go httpS: ... relative paths don't throw an issue on that like absolute paths do if you got miss-matched protocols. That is quite an issue with TW right now. We are way behind on going https: publicly, I think.

Best wishes
Josiah

[Mark S.]

What I do is have a variation of Tobias ximg macros. I have a drop-down list that let's me set the base path of all the <ximg> macros depending on platform. In addition, if a tiddler is tagged with D:2017, then the sub-path of the path name will be /2017. This will allow me eventually to archive or hive off tiddlers by their indicated usage.

Mark 

[TonyM]

Jeremy

That explains the mysterious omission of such a feature. A key use case for me is when I have a folder of images and PDF's I want to display in a tiddlywiki yet I want to avoid loading the tiddly wiki up and making it too big. If I could choose a specific library ..\images Place my files in that and drag and drop to the tiddly wiki it would save a lot of time. Perhaps I do need to provide the relative or absolute path ..\image at the time of the drag and drop (For all that I am about to "import") to use in the creation of the tiddlers, perhaps also an optional check box specifying that I want external links (not importing) on the Import tiddler would make this a low impact change.

Clearly Drag and Drop does have access to the filename of each item dragged and dropped, all we need to do is parse this list as external files/links with the manual provision of the source path.

Another thought is the import feature, permitting import of external links to selected files, and allow a multi-select, I would have thought the browser has to know the full path to do this import?, but I expect I may be wrong on that.

Background (optional reading)

For example I am building an edition of TW5 that I call USD's, Universal Storage Device, A bit like "USB".

On a low cost USB drive I have a tiddlywiki that acts as the WebSite for the USB Drive, I can access this using a OTG Host cable from my smart phone, or tablet. also by placing the USB in a USB port of a computer or on a WiFi access Point. I have a few of these already, One in my car has all the car manuals and service details including the original advertising details. When using a mobile device it is important to keep the size of the Wiki low for performance. I plan to have many of these USD's so If I had a quick way of dragging and dropping or importing external file links it would be helpful. For example I already have 30+ folders containing various content for specific devices such as routers, disk-stations, TVs, Blue Ray Players even the stove and fridge. The thing is with TiddlyWiki, a Cheap USB drive a OTG cable I can USB enable, even website enable anything I want to. I can even glue the USB drive to those things. I have even contemplated putting low cost USB drives on boxes in storage, photographing the items placed in the box, and making these visible in the "USD" TW.  While maintaining a synced copy elsewhere for searching.

Another Use Case
Allowing selective display of Images from a large photo library, or music tracks, curated and placed in a slideshow within a TiddlyWiki that can use tagging and all those features to manage the media. A tiddly-wiki can kind of act as a "PlayList". No these are not transferable, but we do not need to use every feature of tiddlywiki every time.

Please accept my thanks for this beautiful software tool TiddlyWiki, it's open nature makes it resemble "Plasticine" that can be shaped into anything we want. Please never take my apparent criticisms of TiddlyWiki as anything other than because I love it so much and want the best for this gem. And often It is pointed out to me how there is a way already.

Regards
Tony

[Eric Shulman]

On Sunday, August 13, 2017 at 6:31:13 PM UTC-7, TonyM wrote:

Another thought is the import feature, permitting import of external links to selected files, and allow a multi-select, I would have thought the browser has to know the full path to do this import?, but I expect I may be wrong on that.

When the browser shows the "open files" dialog, it allows you to navigate your filesystem and select files... but it does not return the full path to the selected files. Instead, it just returns the "filename.ext" and the file *contents* for each file selected. This is what allows TW to import from files, while still not having knowledge about the directory structure (e.g, path info) for your file system, so it can't be used to "probe" your computer to look for vulnerabilities.

-e

[Mark S.]

But ... as I asked earlier. Is this true if dragging and dropping from an external web site? I suspect not, since knowing the url to a web site is what browsers do all the time. So, it should be possible to drag and drop and then construct a tiddler based on the file type and file name. AND, if that server was the same as the server the TW was on, it should be possible to even to construct a relative path. Then you would have an easy way to add new things to a TW. And since the path is stored in a relative configuration, it would also work as a stand-alone TW with external files. So you could use tiddlyserver to collect data (something that is clunky now) but then use the TW offline (when away from the desktop and/or on mobile devices).

Thanks,
Mark

[TonyM]

Eric,

Yes Understood. Nicely put. But I sill see the following workflow possible,

• Create Images folder below Tiddly wiki
  
• Drag and Drop images to tiddly wiki
  
• Check Import as external files/Or Reference
  
• Enter the relative or absolute path (do the Job the browser will not)
  
• Import

Or

• We could co-opt the import file feature to prompt in a similar way, with multi-select enabled.
• Still asking for the path (relative or absolute)

We could even set another tiddler to contain the relative or absolute path which we edit if we move or even combine the media files into a new single directory or host location we simply edit that and it is reflected in all the relevant items in a given import batch = folder source. 

My skills do not yet permit me to code this so I need to ask the community.

Tony

[TonyM]

Sounds Like a Good Strategy Richard.

Do share if you can.

Tony

[@TiddlyTweeter]

Cari tutti,

A bit out-of-left-field, but somehow relevant, is Riz's experiments from a few months back.

https://ibnishak.github.io/t-blog/

the discussion of it is here.

They are worth a look. They are Node.js generated, not singular TW. I do think they show that a modern, variously CSS styled, flexible blogging framework can be done by TW very well. A LOT of the issue is using CSS better IMO. Riz is good at that.

Best wishes
Josiah