Discussion:
[tw] [TW5] Advice on Node.js Deployment and Wiki Performance
Rick Williams
2014-10-06 16:28:32 UTC
Permalink
Hi All,

We have tw5.1.2 installed for Node.js and with NGINX. We're using a daemon
to run the wiki out of it's own directory (/home/ncemonwiki/emonwiki) and
using SSL to access the nginx server running one the same server.

At initial connect from Chrome browser, it takes about 60 seconds to server
the wiki.

How and what do I need to setup to serve the wiki at speeds comparable to
what I see at tiddlywiki.com ?

Eventually, we'd also like to be able to navigate directly to individual
tiddlers (with permanent url) with less than 3 second response.

Can anyone make suggestions for deployment?

Thanks for any suggestions.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-07 11:50:45 UTC
Permalink
Hi Rick
Post by Rick Williams
We have tw5.1.2 installed for Node.js and with NGINX. We're using a
daemon to run the wiki out of it's own directory
(/home/ncemonwiki/emonwiki) and using SSL to access the nginx server
running one the same server.

That's great to hear.

At initial connect from Chrome browser, it takes about 60 seconds to server
Post by Rick Williams
the wiki.
Ouch.

The current server functionality in TW5 is very primitive, targeting
personal usage. There's no caching within the server at the moment, for
instance, so the main wiki is recomputed from scratch each time it is
requested. There has been some recent work by Nathan Cain to make the
server more flexible and complete, but I'm not sure that it addresses
caching. Anyhow, caching of content is a very feasible improvement.

For the moment, it may be best to use NGINX to implement caching. The main
wiki is very amenable to caching; you can cache the generated HTML file at
any point. When it loads in the browser, it will automatically sync any
tiddlers that have been modified since the HTML file was generated.

How and what do I need to setup to serve the wiki at speeds comparable to
Post by Rick Williams
what I see at tiddlywiki.com ?
http://tiddlywiki.com points to the GitHub Pages repo
https://github.com/Jermolene/jermolene.github.com, so it's served pretty
statically. I'm guessing that caching in NGINX is now fairly competitive
with static hosting, but I'm a big fan of using dumb static servers.
Historically, they've been much more reliable, resilient and speedy than
the sort of hand-rolled HTTP servers we're apt to build (I'm guilty of that
myself, of course).
Post by Rick Williams
Eventually, we'd also like to be able to navigate directly to individual
tiddlers (with permanent url) with less than 3 second response.
I think that that is perfectly feasible.

One other thing I'd like to get working in the server is being able to work
in a mode where we use paths instead of fragment identifiers to select
target tiddlers:

http://127.0.0.1:8080/mywiki/HelloThere

being equivalent to

http://127.0.0.1:8080/mywiki/#HelloThere
Post by Rick Williams
Can anyone make suggestions for deployment?
I think there's other people here and elsewhere with more experience of
NGINX, but hopefully I can help on the TW5 side.

Best wishes

Jeremy
Post by Rick Williams
Thanks for any suggestions.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-07 12:03:56 UTC
Permalink
Post by Jeremy Ruston
One other thing I'd like to get working in the server is being able to
work in a mode where we use paths instead of fragment identifiers to select
http://127.0.0.1:8080/mywiki/HelloThere
Just make the server watch the path and if a .tid changes recreate the
static content and let nginx serve the static file .. super fast, easy
caching, no js bloat for just one tiddler. ....

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-07 12:18:39 UTC
Permalink
Post by Jeremy Ruston
One other thing I'd like to get working in the server is being able to
Post by Jeremy Ruston
work in a mode where we use paths instead of fragment identifiers to select
http://127.0.0.1:8080/mywiki/HelloThere
Just make the server watch the path and if a .tid changes recreate the
static content and let nginx serve the static file .. super fast, easy
caching, no js bloat for just one tiddler. ....
Yes, the caching I'm thinking of for the TW5 server would also work for
changes to transclusions within static tiddler renderings.

Best wishes

Jeremy
Post by Jeremy Ruston
-m
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-07 12:16:56 UTC
Permalink
Post by Rick Williams
We have tw5.1.2 installed for Node.js and with NGINX. We're using a daemon
to run the wiki out of it's own directory (/home/ncemonwiki/emonwiki) and
using SSL to access the nginx server running one the same server.
At initial connect from Chrome browser, it takes about 60 seconds to
server the wiki.
I don't understand, where those 60 seconds come from. It should be not more
than if you go to tiddlywiki.com. ... Assuming you have similar number of
tiddlers and your server is not a watch.

I'm not sure, if I understand "we are using SSL to access the nginx
server". you have a https:// domain? This shouldn't add that much overhead.

What internet connection do you use? downlaod speed?
What is your client hardware?


Eventually, we'd also like to be able to navigate directly to individual
Post by Rick Williams
tiddlers (with permanent url) with less than 3 second response.
TiddlyWiki can build a static html version for every tiddler. So it would
be easy to serve it with nginx. Depending on the location of your server
and the location of the user it shouldn't be more than 400 ms for a static
page. If I load tiddlywiki.com it needs about a second and consider this to
be slow. I personally won't see a page, that needs 3 seconds. I close the
tab after 2 :/ ... joking, but imo 3 seconds is frustrating.

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Rick Williams
2014-10-07 13:23:48 UTC
Permalink
Hi All,


I really appreciate the help and responses on this.

Let me describe my setup in more detail. Perhaps there is some
configuration changes that someone might suggest to help.

My server is in our local data center. Network and server performance
should not be any issue. Keep in mind, all responses are very fast after
the initial connection. It is just in loading the wiki initially where the
delay is - before the first (default) tiddler is presented.
The server itself is a VM with 4 cores, 8GB ram, running CentOS 7.

The config for NGINX is:


# HTTPS server
#
server {
listen 8443 ssl;
server_name stratus.emon.nc.gov;

ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;

ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;

ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

location / {
root /home/ncemonwiki/emonwiki;
auth_basic "Restricted";
auth_basic_user_file /home/ncemonwiki/emonwiki/.htpasswd;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8080;
}
}



The wiki starts via systemd:


[Service]
WorkingDirectory=/home/ncemonwiki/emonwiki
ExecStart=/usr/bin/node /usr/bin/tiddlywiki /home/ncemonwiki/emonwiki
--server
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=ncemonwiki
User=ncemonwiki
Group=ncemonwiki
Environment='NODE_ENV=production'

[Install]
WantedBy=multi-user.target


And the wiki is located under userid ncemonwiki in the home directory:


[***@stratus ~]$ ls
emonwiki
[***@stratus ~]$ cd emonwiki
[***@stratus emonwiki]$ ls -al
total 16
drwxr-xr-x. 3 ncemonwiki ncemonwiki 59 Sep 26 12:36 .
drwx--x--x. 5 ncemonwiki ncemonwiki 4096 Oct 7 09:15 ..
-rwxr-xr-x. 1 ncemonwiki ncemonwiki 329 Sep 26 14:56 .htpasswd
drwxr-xr-x. 2 ncemonwiki ncemonwiki 4096 Oct 6 16:12 tiddlers
-rw-r--r--. 1 ncemonwiki ncemonwiki 239 Sep 26 09:27 tiddlywiki.info
[***@stratus emonwiki]$ cat tiddlywiki.info
{
"plugins": [
"tiddlywiki/tiddlyweb",
"tiddlywiki/filesystem",
"tiddlywiki/codemirror",
"tiddlywiki/highlight"
],
"themes": [
"tiddlywiki/vanilla",
"tiddlywiki/snowwhite"
]
}[***@stratus emonwiki]$ cd tiddlers
[***@stratus tiddlers]$ ls -al
total 1544
drwxr-xr-x. 2 ncemonwiki ncemonwiki 4096 Oct 6 16:12 .
drwxr-xr-x. 3 ncemonwiki ncemonwiki 59 Sep 26 12:36 ..
-rw-r--r--. 1 ncemonwiki ncemonwiki 8186 Oct 3 10:20 ACS_ 5.5 Policy
Model.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 299311 Oct 1 13:59
BlockBDPU_Disabled_Port.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 213576 Oct 1 13:48
BlockBDPUGuard_event.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 158061 Oct 1 13:49
BlockBDPUGuard_event_rule.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 242672 Oct 1 14:00
BlockBPDUGuard_Ticket_Sample.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 49313 Oct 1 14:36
BPDUGuard_event_rule_criteria.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 100637 Sep 30 12:30 Cisco IOS Device
Location.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 166 Sep 26 13:40
$__config_PageControlButtons_Visibility_$__core_ui_Buttons_control-panel.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 173 Sep 29 08:15
$__config_ViewToolbarButtons_Visibility_$__core_ui_Buttons_more-tiddler-actions.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 126 Oct 2 10:53
$__DefaultTiddlers.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 827 Oct 6 16:11 Documentation on
eMon Systems and Tools.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 3352 Sep 26 09:27 emonParseMotd.py.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 40525 Sep 26 13:56 emonUtilBox.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 1135 Sep 30 13:39 emonwiki
Maintenance.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 2370 Oct 1 11:24 Formatted
sysLocation.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 2596 Sep 26 14:05 HP BSM_ Changing
NCFAST Script Password.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 1319 Sep 26 13:14 htpasswd.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 1289 Sep 26 09:27 Linux_ Find Open
Port Process.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 938 Sep 26 09:27 Linux_ Find When
System Last Started_Shutdown.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 509 Sep 26 09:27 Linux_ Using
Systemd.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 265508 Sep 26 13:56
MajorMCServers.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 181 Oct 6 15:47 MARS Archives.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 4509 Oct 6 15:48 MARS Server Info.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 848 Sep 30 13:42 NCeMon Team
Responsibilities.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 824 Sep 30 13:46 NCeMon.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 455 Oct 2 13:01
NCeMon_TiddlyWiki.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 141 Sep 26 12:52 $__SiteSubtitle.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 124 Sep 26 12:49 $__SiteTitle.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 2117 Oct 2 10:48 SOI_ 3.3 Beta
Program.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 1113 Oct 6 16:12 SOI_ Alert Column
Heading Customization.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 792 Oct 2 09:45 SOI_ Email
Templates.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 12656 Oct 6 16:08 soi_image001.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 23888 Oct 6 16:09 soi_image002.jpg
-rw-r--r--. 1 ncemonwiki ncemonwiki 68 Oct 6 16:09
soi_image002.jpg.meta
-rw-r--r--. 1 ncemonwiki ncemonwiki 4291 Oct 1 14:39 Spectrum_ Cisco
Syslog Trap Customization.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 2941 Sep 26 09:27 SystemEDGE_ Custom
Extensions.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 994 Sep 26 09:27 SystemEDGE_ Linux -
Parse motd File.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 1068 Sep 26 09:27 SystemEDGE_
Starting, Stopping, Restarting the SystemEDGE Service.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 921 Sep 26 09:27 SystemEDGE.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 200 Oct 3 15:28 TableTest.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 128 Sep 26 14:47 $__theme.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 104 Sep 26 10:29 $__view.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 203 Oct 6 15:43 WP1ITSPECTEST7.tid
[***@stratus tiddlers]$


The way I understand this is that we are simply forwarding the requests
from nginx to the http server built in to the tiddlywiki program. From the
responses so far, I'm thinking there must be another way to configure this
that I'm missing. I'm wondering where tiddlywiki actually stores the
rendered html content.

Thanks again to everyone.
Post by PMario
Post by Rick Williams
We have tw5.1.2 installed for Node.js and with NGINX. We're using a
daemon to run the wiki out of it's own directory
(/home/ncemonwiki/emonwiki) and using SSL to access the nginx server
running one the same server.
At initial connect from Chrome browser, it takes about 60 seconds to
server the wiki.
I don't understand, where those 60 seconds come from. It should be not
more than if you go to tiddlywiki.com. ... Assuming you have similar
number of tiddlers and your server is not a watch.
I'm not sure, if I understand "we are using SSL to access the nginx
server". you have a https:// domain? This shouldn't add that much overhead.
What internet connection do you use? downlaod speed?
What is your client hardware?
Eventually, we'd also like to be able to navigate directly to individual
Post by Rick Williams
tiddlers (with permanent url) with less than 3 second response.
TiddlyWiki can build a static html version for every tiddler. So it would
be easy to serve it with nginx. Depending on the location of your server
and the location of the user it shouldn't be more than 400 ms for a static
page. If I load tiddlywiki.com it needs about a second and consider this
to be slow. I personally won't see a page, that needs 3 seconds. I close
the tab after 2 :/ ... joking, but imo 3 seconds is frustrating.
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-07 19:46:53 UTC
Permalink
Post by Rick Williams
The way I understand this is that we are simply forwarding the requests
from nginx to the http server built in to the tiddlywiki program.
jup.
Post by Rick Williams
From the responses so far, I'm thinking there must be another way to
configure this that I'm missing. I'm wondering where tiddlywiki actually
stores the rendered html content.
If you request a TW.html from the TW server, the TW server builds an html
file including the TW core, but without the "content" tiddlers.
The browser loads the core and makes a status request to the server
If status is ok, the core requests all the content tiddlers.
If the TW is loaded, the core makes the rendering .. so no communication to
the server
Only if you modify a tiddler, the content goes back and forth again. ..


The only idea I have, is, that the Data center sets the vm to "standby" if
there are no request for a longer time.
So the initial load could be starting the VM + app ... This could be up to
a minute. ... But I think, the server is in use.

What about server load?

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-07 19:54:04 UTC
Permalink
Post by PMario
If you request a TW.html from the TW server, the TW server builds an html
file including the TW core, but without the "content" tiddlers.
One small correction: the HTML file does include the "content" tiddlers.
(It doesn't include them when used with TiddlyWeb).

Best wishes

Jeremy
Post by PMario
The browser loads the core and makes a status request to the server
If status is ok, the core requests all the content tiddlers.
If the TW is loaded, the core makes the rendering .. so no communication
to the server
Only if you modify a tiddler, the content goes back and forth again. ..
The only idea I have, is, that the Data center sets the vm to "standby" if
there are no request for a longer time.
So the initial load could be starting the VM + app ... This could be up to
a minute. ... But I think, the server is in use.
What about server load?
-m
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Rick Williams
2014-10-07 20:43:27 UTC
Permalink
Hi PMario,

That's definitely not the case. I've defined this server myself
specifically for this. There is no competing load of any significance.
Post by PMario
Post by Rick Williams
The way I understand this is that we are simply forwarding the requests
from nginx to the http server built in to the tiddlywiki program.
jup.
Post by Rick Williams
From the responses so far, I'm thinking there must be another way to
configure this that I'm missing. I'm wondering where tiddlywiki actually
stores the rendered html content.
If you request a TW.html from the TW server, the TW server builds an html
file including the TW core, but without the "content" tiddlers.
The browser loads the core and makes a status request to the server
If status is ok, the core requests all the content tiddlers.
If the TW is loaded, the core makes the rendering .. so no communication
to the server
Only if you modify a tiddler, the content goes back and forth again. ..
The only idea I have, is, that the Data center sets the vm to "standby" if
there are no request for a longer time.
So the initial load could be starting the VM + app ... This could be up to
a minute. ... But I think, the server is in use.
What about server load?
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-07 23:06:14 UTC
Permalink
Post by Rick Williams
Hi PMario,
That's definitely not the case. I've defined this server myself
specifically for this. There is no competing load of any significance.
I think I know it.

WARNING: Be aware, that I didn't test the following steps. So ... *backup
;)*

your ls -al says: total 1544 !!

And there seem to be many .png.tid and .jpeg's with several 100kByte ... So
your TiddlyWikki will be huge. ....

IMO you should store your images in an image subfolder and use the
_cannonical_uri field for the image tiddlers.

So your TW stays small and nginx can load the static images on demand. ...
IMO Your startup time should be down quite a bit.

The tiddlywiki.info file has a configuration, that lets you create external
images with the TW build process.
see:
https://github.com/Jermolene/TiddlyWiki5/blob/master/editions/tw5.com/tiddlywiki.info#L32

You should add this to your tiddlywiki.info

"build": {
"index": [
"--savetiddlers","[tag[external-image]]","images",

"--setfield","[tag[external-image]]","_canonical_uri","$:/core/templates/canonical-uri-external-image","text/plain",
"--setfield","[tag[external-image]]","text","","text/plain",
"--rendertiddler","$:/core/save/all","index.html","text/plain"]
},

Then you should add a tag eg: external-image to your .png.tid, png.meta
files.
Same for the .jpg.meta and jpg.tid. ..
Manually or may be a sed script. ..
The tag needs to fit the tag in the tiddlywiki.info build section


Your build commands should look like this:

# I don't know if TW build creates the image dir so we do :)
# Just to be sure.... you have a backup?

mkdir /home/ncemonwiki/emonwiki/images
/usr/bin/node /usr/bin/tiddlywiki /home/ncemonwiki/emonwiki --output
/home/ncemonwiki/emonwiki --build index

Your /images directory should now contain all the images. ... if not
something went wrong.

The build command should create a index.html file, that now should be
relatively small.
(Just a test. Build it again without the --setfield parameters. That's the
file that was served in 60 seconds. .. I'm interested in the size of this
file!)

Now comes the tricky part. ... The build did create images, but didn't
rewrite the .png.tid files in the tiddlers folder.

The (small) index.html should be accessible from a browser. we need to
import it into the server version. ...
If you open the index.html file with a browser you should check some
images.
They should have no text content anymore but a field named _canonical_uri
that points to the image dir ...

- Start the server. Will still be slow.
- Drag and drop the small index.html file to the open TW in the browser
- It should display an import dialog.
- Select all the images, import and pray .....
- The import should rewrite all the image tiddler in the tiddlers folder.
- so this may take some time.

.... If everything goes well ... your TW should be faster now.

If something doesn't make sense. Just ask.

have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-13 10:51:57 UTC
Permalink
@Rick,
Any update about your issue?
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Rick Williams
2014-10-20 17:05:51 UTC
Permalink
Hi Mario,

Thanks for the follow up. I took a bit of vacation but I'm back now.

I followed your instructions and saw some slight differences. The index is
still pretty large and doesn't seem to put new image imports in the
./images folder.

1) I modified the tiddlywiki.info as you suggested:

{
"build": {
"index": [
"--savetiddlers","[tag[external-image]]","images",

"--setfield","[tag[external-image]]","_canonical_uri","$:/core/templates/canonical-uri-external-image","text/plain",
"--setfield","[tag[external-image]]","text","","text/plain",
"--rendertiddler","$:/core/save/all","index.html","text/plain"]
},
"plugins": [
"tiddlywiki/tiddlyweb",
"tiddlywiki/filesystem",
"tiddlywiki/codemirror",
"tiddlywiki/highlight"
],
"themes": [
"tiddlywiki/vanilla",
"tiddlywiki/snowwhite"
]
}

2) I added tags to my existing png and jpg tiddlers (manually).

3) I made the /images directory
4) I ran the /usr/bin/node /usr/bin/tiddlywiki /home/ncemonwiki/emonwiki
--output /home/ncemonwiki/emonwiki --build index

I then started the server and tried it.

My load time is now about 37 seconds. So it's better.

But, my index is still pretty large:

[***@stratus emonwiki]$ ls -alh
total 1.9M
drwxr-xr-x. 4 ncemonwiki ncemonwiki 89 Oct 20 11:45 .
drwx--x--x. 5 ncemonwiki ncemonwiki 4.0K Oct 8 12:57 ..
-rwxr-xr-x. 1 ncemonwiki ncemonwiki 329 Sep 26 14:56 .htpasswd
drwxrwxr-x. 2 ncemonwiki ncemonwiki 4.0K Oct 20 11:45 images
-rw-rw-r--. 1 ncemonwiki ncemonwiki 1.9M Oct 20 11:45 index.html
drwxr-xr-x. 2 ncemonwiki ncemonwiki 4.0K Oct 20 12:43 tiddlers
-rw-r--r--. 1 ncemonwiki ncemonwiki 618 Oct 20 11:45 tiddlywiki.info
[***@stratus emonwiki]$

My tiddlers did seem to get rewritten after the build:

[***@stratus tiddlers]$ ls -al | grep png
-rw-r--r--. 1 ncemonwiki ncemonwiki 181 Oct 20 11:45
BlockBDPU_Disabled_Port.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 175 Oct 20 11:45
BlockBDPUGuard_event.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 185 Oct 20 11:45
BlockBDPUGuard_event_rule.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 191 Oct 20 11:45
BlockBPDUGuard_Ticket_Sample.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 193 Oct 20 11:45
BPDUGuard_event_rule_criteria.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 197 Oct 20 11:45 Cisco IOS Device
Location.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 165 Oct 20 11:45 emonUtilBox.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 171 Oct 20 11:45
MajorMCServers.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 12656 Oct 20 12:46 soi_image001.png.tid
[***@stratus tiddlers]$ cat BlockBDPU_Disabled_Port.png.tid
_canonical_uri: ./images/BlockBDPU_Disabled_Port.png
created: 20141001175956296
modified: 20141020153521294
tags: external-image
title: BlockBDPU_Disabled_Port.png
type: image/png

[***@stratus tiddlers]$

However, notice the file soi_image001.png.tid. This was a new import.
Post by PMario
@Rick,
Any update about your issue?
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Rick Williams
2014-10-20 17:38:10 UTC
Permalink
Oh, another thing...

The images are not displaying now using the normal type of wikitext
reference:

[img[BlockBDPUGuard_event.png]]

Do I need to change the tag here?

I tried this:

[external-image[BlockBDPUGuard <Loading Image...]]
and [img[./images/BlockBDPUGuard
<https://207.192.23.17:12443/#BlockBDPUGuard>_event.png]]

but that didn't work
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-20 20:28:50 UTC
Permalink
You need to tell nginx now to serve the images.

then [img[Loading Image...]] should work.

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-20 20:49:45 UTC
Permalink
Post by PMario
{
"build": {
"index": [
"--savetiddlers","[tag[external-image]]","images",
"--setfield","[tag[external-image]]","_canonical_uri","$:/core/templates/canonical-uri-external-image","text/plain",
"--setfield","[tag[external-image]]","text","","text/plain",
"--rendertiddler","$:/core/save/all","index.html","text/plain"]
},
"plugins": [
"tiddlywiki/tiddlyweb",
"tiddlywiki/filesystem",
"tiddlywiki/codemirror",
"tiddlywiki/highlight"
],
"themes": [
"tiddlywiki/vanilla",
"tiddlywiki/snowwhite"
]
}
looks good to me.
Post by PMario
2) I added tags to my existing png and jpg tiddlers (manually).
3) I made the /images directory
4) I ran the /usr/bin/node /usr/bin/tiddlywiki /home/ncemonwiki/emonwiki
--output /home/ncemonwiki/emonwiki --build index
ok
Post by PMario
I then started the server and tried it.
Did you do the import step? So import the small index.html into the server.
You could select all. ... You did a backup right?
Post by PMario
My load time is now about 37 seconds. So it's better.
total 1.9M
drwxr-xr-x. 4 ncemonwiki ncemonwiki 89 Oct 20 11:45 .
drwx--x--x. 5 ncemonwiki ncemonwiki 4.0K Oct 8 12:57 ..
-rwxr-xr-x. 1 ncemonwiki ncemonwiki 329 Sep 26 14:56 .htpasswd
drwxrwxr-x. 2 ncemonwiki ncemonwiki 4.0K Oct 20 11:45 images
-rw-rw-r--. 1 ncemonwiki ncemonwiki 1.9M Oct 20 11:45 index.html
1.9 MByte ... that's ok. It should be loaded in about a second or so.
Post by PMario
drwxr-xr-x. 2 ncemonwiki ncemonwiki 4.0K Oct 20 12:43 tiddlers
-rw-r--r--. 1 ncemonwiki ncemonwiki 618 Oct 20 11:45 tiddlywiki.info
I'm not sure, what happens if you do the build several times.
If the tiddlers already have the _canonical_uri ... So take care.
Post by PMario
-rw-r--r--. 1 ncemonwiki ncemonwiki 181 Oct 20 11:45
BlockBDPU_Disabled_Port.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 175 Oct 20 11:45
BlockBDPUGuard_event.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 185 Oct 20 11:45
BlockBDPUGuard_event_rule.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 191 Oct 20 11:45
BlockBPDUGuard_Ticket_Sample.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 193 Oct 20 11:45
BPDUGuard_event_rule_criteria.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 197 Oct 20 11:45 Cisco IOS Device
Location.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 165 Oct 20 11:45 emonUtilBox.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 171 Oct 20 11:45
MajorMCServers.png.tid
-rw-r--r--. 1 ncemonwiki ncemonwiki 12656 Oct 20 12:46 soi_image001.png.tid
_canonical_uri: ./images/BlockBDPU_Disabled_Port.png
Post by PMario
created: 20141001175956296
modified: 20141020153521294
tags: external-image
title: BlockBDPU_Disabled_Port.png
type: image/png
However, notice the file soi_image001.png.tid. This was a new import.
Tiddlywiki server doesn't use the "build" info. So it doesn't know about
the images directory to store new images.

The TW server at the moment is a very very basic server to make TW
development easier.

---------

I'm still concerned about the 37 seconds. ...
If you open the dev console in the browser F12
Select the network tab and reload the page.
The timeline should show you, which element needs the time.

Sorry but I'm running out of ideas, atm :)
It probably is something really simple, we just can't see it.

@community: Anyone else? any ideas? nginx experts ?:)

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Rick Williams
2014-10-20 22:03:59 UTC
Permalink
Did you do the import step? So import the small index.html into the server.
You could select all. ... You did a backup right?

I did do this later. But I still winder if it was really necessary.
The image files were already in the images directory.

Tiddlywiki server doesn't use the "build" info. So it doesn't know about
the images directory to store new images.
The TW server at the moment is a very very basic server to make TW
development easier.

OK, I see. Does this mean I need to rerun the 'build' step
periodically to get new image files placed in the right directory?

It also brings up another question about the future plans for the
system. Do you indeed plan to have a more robust server implementation?
After all, the value is in the sharing of information among many. I have no
use for a "personal" wiki.

You need to tell nginx now to serve the images.
then [img[http://yourdomain.lan/image.png]] should work.

Ok. After modifying nginx to add location /images/ the images files are seen as usual:


[***@stratus conf.d]# cat ncemonwiki.conf
# HTTPS server
proxy_cache_path /data/nginx/cache keys_zone=one:10m;
#
server {
listen 8443 ssl;
server_name stratus.emon.nc.gov;

ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;

ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;

ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

proxy_cache one;

location / {
root /home/ncemonwiki/emonwiki;
auth_basic "Restricted";
auth_basic_user_file /home/ncemonwiki/emonwiki/.htpasswd;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8080;
}
location /images/ {
root /home/ncemonwiki/emonwiki;
}
}
[***@stratus conf.d]#



Thanks again for your help.

The load time is still pretty slow - 38 seconds or so. It does take pretty
long over the network to serve the data. I'm turning my attention now to
speeding that up. I have a NAT in the way that I maybe can avoid.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-21 07:55:11 UTC
Permalink
Post by PMario
Did you do the import step? So import the small index.html into the server.
You could select all. ... You did a backup right?
I did do this later. But I still winder if it was really necessary.
The image files were already in the images directory.
Yes, the images are in the image directory already. But the server version
doesn't know about it.
The whole build step creates the index.html file.
It creates the images
It changes the image tiddlers (_canonical_uri, empty text)
... but it doesn't touch the image.png.tid or .jpg.tid files.

So they are still big. If the server starts, it still uses those files.

If the server is started and the index.html is imported, the .png.tid files
are small.
So it seemed to work right in your configuration according to the "ls
tiddlers/" ouput.
Post by PMario
Tiddlywiki server doesn't use the "build" info. So it doesn't know about
the images directory to store new images.
The TW server at the moment is a very very basic server to make TW
development easier.
OK, I see. Does this mean I need to rerun the 'build' step
periodically to get new image files placed in the right directory?
hmmm, That's why I wrote:

I'm not sure, what happens if you do the build several times.
Post by PMario
If the tiddlers already have the _canonical_uri ... So take care.
Since the (small) images are still tagged with "external-image", they are
touched everytime you run the build.
So you need to check if everything is right after a new build run. .... I
just didn't test this case, so I don't know.

Also the import step is needed every time you did import images with the TW
drag and drop action.
The TW binary file handling isn't optimized for this workflow at the moment.

So an alternative version would be to let nginx handle the file upload.
I did a fast search and found this: https://coderwall.com/p/swgfvw
I did a search:
https://www.google.at/search?q=file+upload+ui+for+nginx&tbs=qdr:y
and found:
http://www.howtoforge.com/displaying-upload-progress-with-nginx-on-debian-wheezy

If nginx does the upload handling, there is the problem, that we need to
tell TW about the new file. ....

... As I wrote. The workflow needs to be improved for binary file handling.


It also brings up another question about the future plans for the
Post by PMario
system. Do you indeed plan to have a more robust server implementation?
After all, the value is in the sharing of information among many. I have
no use for a "personal" wiki.
One reason, that makes TiddlyWiki special and unique, is its focus on
beeing an all-in-one single file Wiki. But for your configuration, this is
actually a weak spot.

You are right, _one_ value of a wiki is in sharing it :) And there are
plenty of requests, in making the sharing easier.
But most TW users _don't_ want to touch a server. They request file based
sharing options. ...

But in the TW hangouts we discussed making server more robust.
There is a hangout today:
https://plus.google.com/u/0/events/cd8h7qbbtethtk44i98cq2fmmis

There is a very robust backend for TiddlyWiki. It's called TiddlyWeb. It's
a python app, with a lot of options.
In its basic configuration it uses a similar file based store as the TW
node server.
If you are python guru it should be relatively easy for you to handle it.
If not, it can be overwhelming.

Can you describe your usecase a bit closer, if that's possible.
So I can see, if I should recommend it, or not :)

- How many different wiki's do you need?
- How many users?
- Do you have many different editors?
- or just consumers with a view content editors / creators?

-----------------

There is still the option, to create a completely static version of all
tiddlers, no javascript involved.
This could be served entirely by the nginx server.
So every tiddler is a single page. .... There would be the need for a
different layout, because at the moment the static version uses the same
layout as the js version.


Thanks again for your help.
you are welcome
Post by PMario
The load time is still pretty slow - 38 seconds or so. It does take pretty
long over the network to serve the data. I'm turning my attention now to
speeding that up. I have a NAT in the way that I maybe can avoid.
ok, let us know if it worked out.
Thx for posting your nginx configurations, it will help others, that want
to use TW with a similar configuration.

have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-21 11:48:59 UTC
Permalink
I've added a ticket for properly enabling external images with the
client-server configuration:

https://github.com/Jermolene/TiddlyWiki5/issues/1000

(yay! 1,000 bugs!)

The other route you may be able to explore at the moment is to use the
existing lazy image support, along with caching the .html file in nginx.

Best wishes

Jeremy.
Post by PMario
Post by PMario
Did you do the import step? So import the small index.html into the server.
You could select all. ... You did a backup right?
I did do this later. But I still winder if it was really
necessary. The image files were already in the images directory.
Yes, the images are in the image directory already. But the server version
doesn't know about it.
The whole build step creates the index.html file.
It creates the images
It changes the image tiddlers (_canonical_uri, empty text)
... but it doesn't touch the image.png.tid or .jpg.tid files.
So they are still big. If the server starts, it still uses those files.
If the server is started and the index.html is imported, the .png.tid
files are small.
So it seemed to work right in your configuration according to the "ls
tiddlers/" ouput.
Post by PMario
Tiddlywiki server doesn't use the "build" info. So it doesn't know about
the images directory to store new images.
The TW server at the moment is a very very basic server to make TW
development easier.
OK, I see. Does this mean I need to rerun the 'build' step
periodically to get new image files placed in the right directory?
I'm not sure, what happens if you do the build several times.
Post by PMario
If the tiddlers already have the _canonical_uri ... So take care.
Since the (small) images are still tagged with "external-image", they are
touched everytime you run the build.
So you need to check if everything is right after a new build run. .... I
just didn't test this case, so I don't know.
Also the import step is needed every time you did import images with the
TW drag and drop action.
The TW binary file handling isn't optimized for this workflow at the moment.
So an alternative version would be to let nginx handle the file upload.
I did a fast search and found this: https://coderwall.com/p/swgfvw
https://www.google.at/search?q=file+upload+ui+for+nginx&tbs=qdr:y
http://www.howtoforge.com/displaying-upload-progress-with-nginx-on-debian-wheezy
If nginx does the upload handling, there is the problem, that we need to
tell TW about the new file. ....
... As I wrote. The workflow needs to be improved for binary file handling.
It also brings up another question about the future plans for the
Post by PMario
system. Do you indeed plan to have a more robust server implementation?
After all, the value is in the sharing of information among many. I have
no use for a "personal" wiki.
One reason, that makes TiddlyWiki special and unique, is its focus on
beeing an all-in-one single file Wiki. But for your configuration, this is
actually a weak spot.
You are right, _one_ value of a wiki is in sharing it :) And there are
plenty of requests, in making the sharing easier.
But most TW users _don't_ want to touch a server. They request file based
sharing options. ...
But in the TW hangouts we discussed making server more robust.
https://plus.google.com/u/0/events/cd8h7qbbtethtk44i98cq2fmmis
There is a very robust backend for TiddlyWiki. It's called TiddlyWeb. It's
a python app, with a lot of options.
In its basic configuration it uses a similar file based store as the TW
node server.
If you are python guru it should be relatively easy for you to handle it.
If not, it can be overwhelming.
Can you describe your usecase a bit closer, if that's possible.
So I can see, if I should recommend it, or not :)
- How many different wiki's do you need?
- How many users?
- Do you have many different editors?
- or just consumers with a view content editors / creators?
-----------------
There is still the option, to create a completely static version of all
tiddlers, no javascript involved.
This could be served entirely by the nginx server.
So every tiddler is a single page. .... There would be the need for a
different layout, because at the moment the static version uses the same
layout as the js version.
Thanks again for your help.
you are welcome
Post by PMario
The load time is still pretty slow - 38 seconds or so. It does take
pretty long over the network to serve the data. I'm turning my attention
now to speeding that up. I have a NAT in the way that I maybe can avoid.
ok, let us know if it worked out.
Thx for posting your nginx configurations, it will help others, that want
to use TW with a similar configuration.
have fun!
mario
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-21 14:11:57 UTC
Permalink
Post by Jeremy Ruston
https://github.com/Jermolene/TiddlyWiki5/issues/1000
(yay! 1,000 bugs!)
yay ... when you closed it :)
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
HansWobbe
2014-10-21 21:48:05 UTC
Permalink
<:-) All together now ... "999 bottles of beer on the wall..." / :-) >
Post by PMario
Post by Jeremy Ruston
https://github.com/Jermolene/TiddlyWiki5/issues/1000
(yay! 1,000 bugs!)
yay ... when you closed it :)
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Rick Williams
2014-10-22 21:35:14 UTC
Permalink
Hi Mario,
Can you describe your use case a bit closer, if that's possible.
So I can see, if I should recommend it, or not :)
- How many different wiki's do you need?
I expect to have separate wiki's for different functions. They would be
distinct, and not share any data. So, they may even be on different VMs.
Although, perhaps we can run more than one on a server.
- How many users?
I'm expecting a relatively small number of users. Perhaps only 40 or so
individuals and perhaps 5-15 concurrent.
- Do you have many different editors?
- or just consumers with a view content editors / creators?
The use case scenario is primarily for IT staff. We have several areas that
document their "processes" for how to handle particular issues, problems,
or steps for implementation of service requests. The wiki would be used to
describe these processes. We then have a system that presents real-time
alarms and events to operations staff. The idea is to have the alarm relate
to a "process" such that a staff member can 'right-click' an alarm/event
and go directly to the wiki page (tiddler) that defines the process they
should follow. The processes (tiddlers) will be maintained and edited
primarily by tier-2 and -3 support staff.

So, for this particular use case, we envision:
- about 200 or so tiddlers equating to processes.
- about 5-10 concurrent viewers
- about 30 content creators but only expect about 10 maximum concurrent
editors and they'd likely be editing different things.
-----------------
There is still the option, to create a completely static version of all
tiddlers, no javascript involved.
This could be served entirely by the nginx server.
So every tiddler is a single page. .... There would be the need for a
different layout, because at the moment the static version uses the same
layout as the js version.
Can you point me instructions for deployment of a static environment built
from a standard TW5 wiki?
Thanks, again,
Rick
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
PMario
2014-10-23 08:55:31 UTC
Permalink
This post might be inappropriate. Click to display it.
PMario
2014-10-23 08:57:22 UTC
Permalink
Post by PMario
build static command: node tiddlywiki.js yourEdition --build static
build all command: node tiddlywiki.js yourEdition --build
don't forget to define --output directory
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
Loading...