Menu

#320 Setup: Change wiki folder location / layout

PFE
pfe
nobody
setup (3)
v1.4.*
2014-10-10
2014-03-06
gnosygnu
No

Curently, XOWA has a number of restrictions regarding a wiki

  • A wiki must be located underneath /xowa/wiki/
  • A wiki must have parallel directories in /xowa/file/ and /xowa/user/anonymous/wiki/
  • A wiki cannot be one single file

I'm planning to remove these restrictions within the next two months. This ticket will track the progress of all three items.

Discussion

  • Anonymous

    Anonymous - 2014-03-06

    I was thinking that besides implementing a changable path for the offline wiki data (e.g. within xowa GUI) -see last post at http://sourceforge.net/p/xowa/tickets/270/ -, it might also be handy to have the path to the location of user_custom_cfg.gfs (currently \user\anonymous\app\data\cfg\user_custom_cfg.gfs ) changable inside xowa as well. That way, with every new update of xowa, people no longer need to move that file out of the old xowa version folder and into the new xowa version folder (for example by specyying a path to a higher-up folder such as \win_configfiles\ or something).

     
  • gnosygnu

    gnosygnu - 2014-03-07

    I don't know if you realize this, but you can just go to home/wiki/Help:Options/Config_script. This is the same as directly editing \user\anonymous\app\data\cfg\user_custom_cfg.gfs.

    Eventually, all files will move into a single user database, which will either

    • be located in the xowa root directory: /xowa/xowa.user.anonymous.sqlite3
    • or redirected through a command-line switch: --user_db --D:\my_settings.sqlite3

    However, this will probably fall in the scope of another ticket, not this one.

     
  • Anonymous

    Anonymous - 2014-03-07

    Yes, I was aware of that. Saving newly inserted text there didn't work with me however, so manually updating the gfs outside xowa (using notepad++) was the only thing that worked. Regardless, even if that worked, the method still requires additional work to be done with every update of xowa, namely the moving of the gfs to a safe location before the old version of that folder is removed and the new version of the folder is put in to replace it (see http://sourceforge.net/p/xowa/tickets/159/?page=2 , post beginning with "Hi gnosygnu,")

     
  • gnosygnu

    gnosygnu - 2014-03-10

    Saving newly inserted text there didn't work with me however, so manually updating the gfs outside xowa (using notepad++) was the only thing that worked.

    Why exactly did it not work? Even with your strange layout of /xowa/win, /xowa/linux, /xowa/macosx, the home/wiki/Help:Options/Config_script would still work in each OS. Specifically:

    • Run /xowa/win/xowa.exe
    • Go to home/wiki/Help:Options/Config_script
    • Enter your script. Script is saved
    • Run /xowa/linux/linux.sh (the separate directory is not my recommendation)
    • Go to home/wiki/Help:Options/Config_script
    • Enter your script. Script is saved
    • etc..

    Of course, you're triplicating your work, but that's because of your insistence on putting xowa in three separate directories instead of one.

    (see http://sourceforge.net/p/xowa/tickets/159/?page=2 , post beginning with "Hi gnosygnu,")

    I've replied in length to that post. The only thing I'll add here is repeat the above:


    Eventually, all files will move into a single user database, which will either

    • be located in the xowa root directory: /xowa/xowa.user.anonymous.sqlite3
    • or redirected through a command-line switch: --user_db --D:\my_settings.sqlite3

    However, this will probably fall in the scope of another ticket, not this one.


    Even if you decide to go ahead with your "multiple OS" directories, then the command-line switch should work in this scenario.

     
  • Anonymous

    Anonymous - 2014-03-22

    [Edited by gnosygnu for format]

    I just wanted to comment on your last post at http://sourceforge.net/p/xowa/tickets/159/?page=3

    In regards to the paths mentioned (both ending with "user\anonymous\data"); these were indeed the same, the only difference is the /atcolib/ and /xowa_win_v1.3.1.1/ folder, of which I know you don't like these. So, I just suggested both options so you can leave out those folders if you prefer.

    In any case, I do suggest to use seperate folders, higher up. You mentioned you would place the file at C:\xowa\xowa.user.anonymous.sqlite3 ,however I have some doubts on this:

    • as mentioned at http://sourceforge.net/p/xowa/tickets/159/?page=2, xowa best gets a folder for each user (ie /anonymous/ , /user1/ , /user 2/, ...). That way, user data (including user article changes) can be kept seperate. This would be very important to allow sharing a wiki, and backtracing what changes a particular person has done to which articles. This, to allow easy reverting of particular changes, while keeping other changes that person did in place.

    • in addition, it might also be best to have the /anonymous/ and other user files (/user1/, /user2/, ...) folder per wiki, -this is also why I proposed to put it at the offline or online wiki folder (say wiki/atcolib/ -or in my case, /atcolib/wiki/atcolib/ -). Else, all user history of the user "anonymous" (which might include user history of multiple wikis, as the user "anonymous" occurs in all wikis) would be kept in a single file/folder. To reduce file size/eliminate useless data, and hence facilitate wiki sharing, it's best to keep it seperate (perhaps similar to how I initially suggested it). When people use multiple wikis, as you suggested, they will also have multiple xowa.user.anonymous.sqlite3 files (as, as mentioned above, each wiki has an anonymous user account). I have thought again about your previous comment btw, and I think it is also best to seperate off the user preferences data (which I assume is also in xowa.user.anonymous.sqlite3) from the anonymous user history data; the user preferences data can then be stored higher up, for use by all wikis (say at /userpreferences/ -or in my case /atcolib/userpreferences/-)

    In annex, you'll find some images. I noticed that there is no default image that is loaded if no offline images are found in the path specificed at xowa. That looks weird (it just shows the captions then, and there is no indication of the size of the image. Perhaps you can consider adding the imageneeded image to xowa, see annex
    I also included the jane doe avatar image and the john doe image avatar as profile images for the users, you can use these, or implement other similar images.

    Finally, I just wanted to mention the program Doublekiller, this free program might be useful for many people that wish to clean up offline image folders (removing duplicate images). There is a direct download link for it at http://download.cnet.com/DoubleKiller/3000-2248_4-10407004.html, so that avoids needing to use some installer (these are generally infested with spyware). Perhaps you may want to mention it at one of your help articles for the xowa users.

     

    Last edit: gnosygnu 2014-03-24
    • Anselm D

      Anselm D - 2014-03-22

      Finally, I just wanted to mention the program Doublekiller, this free program might be useful for many people that wish to clean up offline image folders (removing duplicate images).

      FYI: I like to use AllDup for that, it can additionally create "hard links"/"NTFS junction point" at NTFS instead of deleting the duplicate files. So you can save the space and do not loose the references. I use it also at Linux with Wine. At Linux filesystems it creates symbolic links instead of hard links. Links are only useful if you do not change the contents of the files/images. If you do this at one file, you do it also at the duplicate files.

      AllDup - Picture Duplicate Finder Software, Find Hard Links
      http://www.allsync.de/alldup_help/alldup.htm

       

      Last edit: Anselm D 2014-03-22
      • gnosygnu

        gnosygnu - 2014-03-24

        Hi. As per my comment below, XOWA's policy is to use open-source software only. Thanks.

         
    • gnosygnu

      gnosygnu - 2014-03-24

      So, I just suggested both options so you can leave out those folders if you prefer.

      I thought we agreed that the other option was no longer worth discussing.

      xowa best gets a folder for each user (ie /anonymous/ , /user1/ , /user 2/, ...)

      The new format would have each user have their own file. This is barely different than a separate folder.

      This would be very important to allow sharing a wiki, and backtracing what changes a particular person has done to which articles.

      • Backtracking changes is not currently supported by XOWA, and will probably not be for several months (at least)
      • Whenever backtracking changes are supported, these changes would go into the "wiki" folder, not the "user" folder. This is just like MediaWiki, which keeps track of changes within the wiki data directly.

      Else, all user history of the user "anonymous" (which might include user history of multiple wikis, as the user "anonymous" occurs in all wikis) would be kept in a single file/folder.

      All user history is already kept in a single file today.

      I think it is also best to seperate off the user preferences data (which I assume is also in xowa.user.anonymous.sqlite3)

      Yes, it is

      from the anonymous user history data;

      Eventually the history data will be placed in the xowa.user.anonymous.sqlite3 file as well.

      In short, I may support overrideable options in the /wiki/ folder, but the first pass will be options at /xowa/xowa.user.anonymous.sqlite3

      I noticed that there is no default image that is loaded if no offline images are found in the path specificed at xowa. That looks weird (it just shows the captions then, and there is no indication of the size of the image)

      This behavior is just like MediaWiki. If no image is present, it just shows the caption.

      I also included the jane doe avatar image and the john doe image avatar as profile images for the users, you can use these, or implement other similar images.

      Thanks for uploading these images, but I don't know what can be "implemented" with them. As said above, the "show caption if no image" behavior is just like MediaWiki, and I have no plans to change it.

      Finally, I just wanted to mention the program Doublekiller

      XOWA's policy is to use open-source software only. Currently the only exception is Operating Systems support (Windows / Apple), which is sadly unavoidable.

       
  • Anonymous

    Anonymous - 2014-04-05

    I think I first best explain the operation of the sharing of the wiki better.
    Obviously, since it is an offline wiki, "real-time" collaboration (as on wikipedia, ...) can't be done.
    Rather, to collaborate, an FTP-site would be set up, where a first user uploads the initial offline wiki/xowa.
    Then, another user -user2- (after downloading it) adds a range of edits, and reuploads that to the FTP site again (under a different folder). This is picked up by the first user (or another user again) and the cycle continues.

    Now, the trouble is that if say user 2 has done his edits without logging in, the edits will be done by the user "anonymous" (and have changed xowa.user.anonymous.sqlite3 . If user 2 had 2 offline wikis (one from the FTP site, another from somewhere else), edits on both wikis will be saved to the xowa.user.anonymous.sqlite3 file, making it much more difficult for the next user -user3- to see which edits he actually did to the single offline wiki that is downloaded from the FTP site. That makes it harder for him to correct edits that should be reverted, ... Another (less important) difficulty is that the users may have different settings (preferences) and the location of the offline wiki may be different (different path specified for images, location of wiki/xowa on hard drive); this latter issue can be changed every time by each user that downloads the wiki/xowa off course, but it's an extra annoyance nonetheless.

    So, to avoid all this, I suggest to seperate the user history from the preferences and make sure the data from the user anonymous only stores history from the anonymous user of 1 specific wiki.

    There was also one other thing I forgot to mention: in my preposition the user preferences would be seperated anyhow from the
    user history, so to make things more clear, the /user/ folder would be best renamed to /userhistory/

    Another thing that may be added in the future is the ability to log in (I assume this is not yet possible); that way it would be easier to see which edits were done by whom by people that downloaded the offline wiki from an FTP site. Usernames like edits_FTP_site_upload_1, edits_FTP_site_upload_2 can then be made. It still doesn't adress the issue that arises when a particular username edits several wikis at once, so the above still needs to be implemented to adress that issue.

     
    • gnosygnu

      gnosygnu - 2014-04-07

      make sure the data from the user anonymous only stores history from the anonymous user of 1 specific wiki.

      Thanks for thinking about this, but I believe your proposal just wouldn't work. For example:

      • Person_1: adds page "Page_1"
      • Person_2: renames page "Page_1" to "Page_2"
      • Person_1: modifies text to "Page_2"
      • Person_2: modifies text on "Page_2"

      If Person_1's history was stored in one database and Person_2's history was stored in another database, there is no way to meaningfully view the history unless one has both databases.

      This would be what Person_1 sees:

      • Person_1: adds page "Page_1"
      • Person_1: modifies text to "Page_2"

      This would be what Person_2 sees:

      • Person_2: renames page "Page_1" to "Page_2"
      • Person_2: modifies text on "Page_2"

      Not only does this not make sense, there is no way to revert changes.

      This is just one scenario. There are many more. In the end, all the history needs to be together in one database. Splitting it up per user is just asking for complications.

      user preferences would be seperated anyhow from the user history

      I really think this should be opaque to the user. For example, Firefox has one "profile" directory per user. I'm planning to have one "profile" database. If the user wants separated data (history, preferences, bookmarks), then I'd rather create an export feature, rather than create different files

      Another thing that may be added in the future is the ability to log in

      I'll probably add that in the future, but its usefulness will be low until editing wikis are fully supported.

       
  • Anonymous

    Anonymous - 2014-04-08

    If Person_1's history was stored in one database and Person_2's history was stored in another database, there is no way to meaningfully view the history unless one has both databases.

    --> This problem would never occur, as people would generally post the entire wiki + xowa (rather than say just the /wiki/atcolib folder and the /userhistory/ folder ) I think it is only good practice to post the entire thing because besides these folders, the wiki would also need an /imagedump/ folder, ...

    If you're referring to the accidental deleting of users (which can occur if the person doing the edits and wiki/xowa FTP upload has several wikis he's editing and wishes to delete any users that were contributors to the other wiki he was also editing); this too is impossible. This, as -as mentioned before-, the users would be grouped by wiki. So if the wiki is called "atcolib", there would be a folder /user/atcolib/ in which the users are placed (for example: /anonymous/, /user1/, /user2/, ...) If we assume he was also editing another wiki (say "airplane_wiki"), then there would equally be a folder /user/airplane_wiki/ with users like /anonymous/, /user1/, /user2/, ...

    In regards to the amount of databases (xowa.user.XXX.sqlite3 files): the amount of these files would normally also be rather small, simply because most people don't bother making a username/logging in. So, most userhistory would be in the anonymous user account. That immediatelly also creates a problem as due to the huge amount of edits, finding specific edits in the userhistory and/or reverting edits will prove very difficult, making the feature rather ineffective. Finally, I don't think there would be a problem, even if a lot of usernames were made and thus a lot of xowa.user.XXX.sqlite3 files were made. As mentioned above, no manual deleting of users would need to be done, and the whole folder (and even many folders above it/entire wiki&xowa) can just be uploaded to the FTP site.

    PS: a few months ago I posted the atcolib wiki and xowa on an FTP site (well, box-account). If you like to see it for an example, here's the adress:
    http://healingweb.blogspot.be/
    https://app.box.com/s/gh4dt33u7h7hd8l3fm53
    https://app.box.com/s/rlv4k0qm814sql6blar3

     
  • gnosygnu

    gnosygnu - 2014-04-11

    This problem would never occur, as people would generally post the entire wiki + xowa post the entire wiki + xowa

    I'm not sure I understand your purpose. You seem to agree that the history is useless unless the entire history is available. If so, then why go through the trouble of separating the history into these individual user databases?

    If you're referring to the accidental deleting of users

    Honestly, this concern never entered my mind. As I've indicated before, I believe in letting the user shoot themselves in the foot as many times as they want to. I'm not going to put in code to prevent them from doing it.

    So, most userhistory would be in the anonymous user account. That immediatelly also creates a problem as due to the huge amount of edits, finding specific edits in the userhistory and/or reverting edits will prove very difficult, making the feature rather ineffective.

    I think your approach differs widely from that of MediaWiki. Specifically:

    • Users log in to their own account in MediaWiki
    • Users don't go finding edits to revert; they revert the edits on a given page

    I've said before that I am more interested in paralleling MediaWiki's approach. I know you're concerned about decentralized editing, but frankly...

    • This will not be part of the first pass of XOWA's editing functionality
    • XOWA's editing functionality is still several months away
    • Decentralized editing is much more difficult than the scenarios proposed above

    I really don't see much point in trying to going through this exercise now.

    a few months ago I posted the atcolib wiki and xowa on an FTP site (well, box-account).

    Thanks for the links. I haven't had time to review them, but I wish you good luck with your efforts.

     
  • Anonymous

    Anonymous - 2014-04-15

    I'm not sure I understand your purpose. You seem to agree that the history is useless unless the entire history is available. If so, then why go through the trouble of separating the history into these individual user databases?

    --> Quite simple: to reduce file size (as well as overcomplicated anonymous userhistory due to edits of several wikis) which, regardless of the method used, requires the solving of the problem of the /anonymous/ userhistory. /anonymous/ userhistory is currently not present per wiki database (instead the anonymous userdata of any edited wikis is saved in a same file).

    I agree that seperating off the rest of the users individually is not specifically needed (could be stored in a single database (say xowa.user.notanonymous.sqlite3 in the folder /user/atcolib/ ) but perhaps that if you're allready doing the work of seperating the anonymous user per wiki, making individual users besides this anonymous user (instead of a single xowa.user.notanonymous.sqlite3 file) isn't that much more work, and has some advantages (for example entirely deleting of banned users and their userdata from a wiki, immediatelly showing the amount of users even from outside the program, ...).

    As mentioned before, deleting userhistory from an entire wiki (for example from one the user is editing but which he deosn't wish to upload to the FTP site; such as the airplane_wiki example in one of my previous posts) is useful, for example for people wishing to upload the wiki on an FTP site; since all userhistory of a seperate wiki is removed, it could definitly add up over time, making it a rather important feature to add.

    Finally, something else I forgot. I noticed the puzzlepiece logo of XOWA. I was thinking about it and it doesn't seem like the most correct logo, especially as the logo is from wikipedia which is itself a project of WikiMedia. Also, although the wikipedia articles can be downloaded with XOWA, any other wiki can be downloaded as well and there is also a focus on off-line use of articles (something which wikipedia does not focus on). So, some alternative logo's are:

     
  • gnosygnu

    gnosygnu - 2014-04-16

    Quite simple: to reduce file size

    This is pointless. I've explained before that the individual user databases are useless. You need the entire history for it to be usable. Whatever benefit you think you're gaining from "reducing" the file is meaningless. The resulting file is not useful, no matter how small it might be.

    To quote from before:

    You seem to agree that the history is useless unless the entire history is available.

    And to repeat it again in another form:

    Splitting the history database into parts is pointless because the individual parts are useless. I don't know how many times I have to say this.

    I noticed the puzzlepiece logo of XOWA.

    You're telling me you finally noticed the logo now after it's been there for ten months?

    I was thinking about it and it doesn't seem like the most correct logo, especially as the logo is from wikipedia which is itself a project of WikiMedia

    So, let me get this straight. This is a logo...

    • That was proposed after deliberate consideration by one user...
    • That was carefully tweaked for appearance by another user...
    • That has been used by XOWA for the past 10 months...
    • That has been shown by other websites to represent XOWA...

    And I should consider changing it, simply because you just noticed it now and don't feel it is "correct"?

    So, some alternative logo's are:
    the wikimedia logo (see http://en.wikipedia.org/wiki/File:Wikimedia_logo_family_2013.svg ),

    Are you serious? After you dismiss the current logo as being too much like Wikimedia, your first suggestion is another Wikimedia logo? And one that screams "Wikimedia" more so than the puzzle piece?

    but perhaps this is best not used neither

    And yet, you still left it as your first suggestion. Why not do some self-editing and remove these half-formed thoughts completely?

    the mundaneum logo

    No. Absolutely not. The logo has IP issues: http://expositions.mundaneum.org/fr/disclaimer

    And even if it didn't, I am simply not going to replace the current logo with another logo based on a random personal whim.

     
    • Anonymous

      Anonymous - 2014-04-18

      As I stated before, you decide on how to proceed since it is your program. I just give some proposals in my messages (well intented), and you can do with it as you like, and I never presume that my ideas will actually be implemented, rather the opposite. I guess I'm sometimes a bit bold (which may be a side-effect of using the wikipedia so much -which actively promotes "being bold"- (though that's not an excuse). Anyhow, if I have indeed been to bold, sorry about that.

      Re the logo:
      I've seen the logo allready off course but never thought about it any further untill now. Also, having the most suitable logo for xowa was untill now also of little importance, and ultimately, it should be your personal taste as well (as you made the program). There are also many other logo's you can potentially use as an alternative, such as the shutdown logo -referring to the offline use of wikis- . It is the same as the one you use for your account at this forum, another is found at http://openclipart.org/detail/127261/clarity-shutdown-icon-by-kuba and many others.

      Perhaps you could simply make the logo changable by the user instead, by having him change the logo image (you can detail how to do this in the help pages). That would be in line with the "skin" idea I proposed a while back which could remove one of the search fields as well. Also, having the logo changable is done by i.e. Shoutwiki, ... and I believe may also be possible in MediaWiki, ...

       

      Last edit: Anonymous 2014-04-18
  • gnosygnu

    gnosygnu - 2014-04-24

    Anyhow, if I have indeed been to bold,

    I don't mind the boldness, nor the suggestions. I do feel like you are too entrenched in your thinking, and do not actually read my comments. A common theme in many of our exchanges is "I've said this before, and I'll say it again." A prime example is the instructions for the offline image folder: I gave the same instructions 3 times, and then had to stop and write a full multiple-step walk-through in order for you to read it and follow it. This recent exchange is another example of my stating repeatedly "user databases are useless". After a while, this gets very frustrating on my side and it needlessly takes up a lot of time.

    ultimately, it should be your personal taste

    I've pointed out that at least one other user was responsible for the logo decision, so it was not strictly a matter of "my personal choice".

    It is the same as the one you use for your account at this forum

    The logo floating over my name was chosen by sourceforge. I made no deliberate selection.

    Perhaps you could simply make the logo changable by the user instead, by having him change the logo image (you can detail how to do this in the help pages).

    Logos are changeable for any given wikis. I believe I've given you the instructions before, but just to be clear, you'd change the logo at /xowa/user/anonymous/wiki/name_of_wiki/html/logo.png.

    If this becomes a frequent request, I'll add an entry to the FAQ. I have yet to hear someone ask for their own customized logo -- particularly for the XOWA home wiki. I'd imagine that those who wanted to change it, just did the following:

    • Clicked "View HTML"
    • Found out where the logo was being pulled from
    • Changed the file on their own.
     

    Last edit: gnosygnu 2014-04-24
  • gnosygnu

    gnosygnu - 2014-10-10
    • status: new --> pfe
     

Anonymous
Anonymous

Add attachments
Cancel