Questions / Feature Requests (maybe)... seeing what I can do with MWS compared with what i did with TWS
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- backend
Hướng nghiên cứu
Start by reading the MultiWikiServer documentation and its existing wiki configuration and plugin handling entry points; the issue does not name files or tests. Compare the requested plugin stores, shared files, included wiki templates, and tag based organization with what the project supports. Done would require clarifying which capabilities are missing and defining their scope; this issue alone does not identify a specific change or completion test.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Question on MWS compared with what I was doing in TWS
a lot of this is wrapped in rpg management because that is what I was using it for, could apply to uses in a lot of wikis types
i could have made the questions more generic but I used what I know
Trying to figure out if MWS would work with my projects workflow.
Basically is this possible? Is this something that would work now or will come later?
PluginStore...
In TiddlyServer I had a folder "MyPluginStore"
I did "twplugins='./wikis/MyPluginStore'" in my "start.sh" file.
All I had to do was put the plugin in the "MyPluginStore" folder under the correct name space.
Then in the Wiki's "tiddlywiki.info" I wanted to use that plugin I just included the correct name space under plugins.
MyPlugins...
In TiddlyServer I had a folder MyCustomPlugins.
I had one wiki for each plugin or plugin family with documentation and tests.
I then did "twplugins+=':./wikis/MyCustomPlugins/FieldRunnerPlugin/plugins'" in my "start.sh" for each custom plugin that I would require.
Then in the Wiki's "tiddlywiki.info" I wanted to use that plugin I just included the correct name space under plugins.
Unattached shared .tid and .json...
In TiddlyServer I used "FileSystemPaths" to direct the output of certain tagged tiddlers into a common shared folder in my wikis folder.
Mostly just .json tiddlers.
Before I figured out how to use the FileSystemPaths I moved them by hand.
Another reason for moving them by hand was I created a lot, A LOT, of them before understanding shares as well.
WikiTemplate...
My own designation for a Wiki that had the default look and feel I wanted along with some common css, and by default the settings I had made on that wiki.
All my later wikis pulled this wiki in first using "includeWikis". Any time I wanted to make a change I changed the WikiTemplate and refreshed the server, changes would then be reflected on the wikis unless of course I messed up and had changed something on the target wikis... that was fun figuring out at times where I had overrrided the included wiki.
I had even created a bit of a hierarchy (a inheritance of included wikis)...
with a BaseTemplate wiki
A CampaignTemplate that pulled in "includeWikis" the BaseTemplate than had things custom to displaying campaigns
A ManualTemplate that pulled in "includeWikis" the BaseTemplate and again was customized for diplaying manuals.
Then My wikis would load "includeWikis" one of the three templates.
Organizing tiddlers...
Guessing this one would be a given for being able to pull just specific tagged tiddlers from other wikis but asking to clarify.
I used "FileSystemPaths" to organize tiddlers in wikis under folders and subfolders based on tags.
I mean the tags were already there and used for sorting and such why not use them to organize the folder structure.
End result I could use the "shared" folder and the "tiddlywiki.files" using "directories" to point to all the "monster folder" or the subfolder "undead" or to the sub-subfolder "skeleton", as an example. I could cast a wide net or be specific on what was available in the wiki accessing the shares.
This worked well for dealing with NPC wikis, especially with versions of NPC's where the NPC grows over a campaign. Then monsters, items, etc. etc.
Ultimately when I needed a module wiki for a game I would save out a standalone wiki and everything was wrapped up in a neat ready to use stand alone wiki. I think the worst case scenario I ran into was I had to drag drop some plugins into the stand alone wiki, I may have fixed that though because I do not remember it being a problem later on.
Thanks, frakier
And sorry to be a pain.
- Ngôn ngữ chính
- TypeScript
- Star
- 60
- Fork
- 17
- Merge trung bình
- 4 phút
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của TiddlyWiki/MultiWikiServer
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 57/100
TiddlyWiki/MultiWikiServer#145 · 8 bình luận ·
-
ci.yml fails on pushĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 48/100
TiddlyWiki/MultiWikiServer#144 ·
-
rpm v12 and allowScripts problemĐang mở
Độ khó 3/5 1-3 giờ Mức phù hợp với người mới 15/100
TiddlyWiki/MultiWikiServer#141 · 2 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
TiddlyWiki/MultiWikiServer#140 · 4 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
TiddlyWiki/MultiWikiServer#139 ·
Tất cả issue của TiddlyWiki/MultiWikiServer
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Northeastern-Electric-Racing/FinishLine#4660 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
BeOS .json missingĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
mihaip/infinite-mac#475 ·
-
Let TypeScript accept an initial object in ReactiveDictCó thể đã có người làm @yograj-vijay-yadav đã nhận hôm nay. Đang mởbug good first issue help wanted workshop
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 92/100
meteor/meteor#14919 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
marmelab/atomic-crm#401 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
account: profile
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 5 ngày